If you’re using Azure AD, and have Hybrid Azure AD joined machines, special considerations must be made with non-persistent VDI workstations and VMs. This applies to Instant Clones on VMware Horizon.
Due to the nature of non-persistent VDI, machines are created and destroyed on the fly with a user getting an entirely new workstation on every login.
Hybrid Azure AD joined workstations not only register on the local domain Active Directory, but also register on the Azure AD (Azure Active Directory).
The Problem
If you have Hybrid Azure AD configured and machines performing the Hybrid Join, this will cause numerous machines to be created on Azure AD, in a misconfigured and/or unregistered state. When the non-persistent instant clone is destroyed and re-created, it will potentially have the same computer name as a previous machine, but will be unable to utilize the existing registration.
This conflict state could potentially make your Azure AD computer OU a mess.
VMware Horizon 8 version 2303 now supports Hybrid Azure AD joined non-persistent instant clones using Azure AD Connect. If you are using an older version, or using a different platform for non-persistent VDI, you’ll need to reference the solution below.
The Solution
Please see below for a few workarounds and/or solutions:
- Upgrade to VMware Horizon 8 2303
- Use Seamless SSO instead of Hybrid Azure AD join (click here for more information)
- Utilize login/logoff scripts to Azure AD join and unjoin on user login/logoff. You may have to create a cleanup script to remove old/stale records from Azure AD as this can and will create numerous computer accounts on Azure AD.
- Do not allow non-persistent virtual machines to Hybrid Domain Join. This can be accomplished either by removing the non-persistent VDI computer OU from synchronization with Azure AD Connect (OU Filtering information at https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-sync-configure-filtering) or by disabling the scheduled task to perform an Azure AD join.
In my environment I elected to remove the non-persistent computer OU from Azure AD Connect sync, and it’s been working great. It also keeps my Azure Active Directory nice and clean.
[…] Whether deploying VDI for the first time or troubleshooting existing Azure AD SSO issues for an existing environment, special consideration must be made for Microsoft Azure AD SSO and VDI. […]
What should a login/logoff script include/do? Just dsregcmd /join and /leave?
Hi Rob,
It would be something like that: join on logon, and then leave on logoff. Note that you’ll end up with a ton (every increasing) number of devices on your Azure AD which will require cleanup (you may be able to script the cleanup).
Also, please note that this is only supported with AD Federated, if you do this without AD Federation it’s unsupported.
Hi Stephen and Rob,
If you are in a supported configuration, meaning you have an Azure hybrid federated ID model, then you shouldn’t have to do a dsregcmd /leave . In fact the official MS documentation explicitly says not to and it is the reason you are ending up with a lot of stale objects.
https://learn.microsoft.com/en-us/azure/active-directory/devices/howto-device-identity-virtual-desktop-infrastructure
“For Windows current in a Federated environment (for example, AD FS):
Implement dsregcmd /join as part of VM boot sequence/order and before user signs in.
DO NOT execute dsregcmd /leave as part of VM shutdown/restart process.”
With ADFS or any supported IDP for that matter, you are registering the device to Azure AD directly using an IDP-generated device-specific auth token at device startup/logon to successfully register the device and complete hybrid AD join. Executing the dsregcmd /join at every startup ensures that the DRS intelligence is there to update the existing device object and its creds in Azure AD and provide the Azure device creds back to the registering device. Presumably the “intelligence” rests in the claims in the IDP-generated token always being the same per device so that DRS knows the registration request is for the same/already existing object.
This is why you don’t need dsregcmd /leave in the supported federated model and the same device object can be updated as non-persistent VDI clients are spun up. MS has no equivalent DRS intelligence for a managed domain scenario….yet(???) = unsupported. It will work (sort of) but not consistently due to the ADConnect sync dependency introduced in the managed scenario for DRS.
The problem with #2 is that you don’t get seamless SSO nor conditional access for the VDI devices out of the scope for ADConnect sync, which is worth mentioning.
Hi Karif,
The stale objects occur when people are using an unsupported method, which includes the use of the “dsregcmd /leave” command. This isn’t needed if you’re using ADFS and using Hybrid joined machines with ADFS.
This is a common theme I regularly see as a lot of environments are using unsupported configurations.
Stephen
Can you point us to the documentation on this:
“VMware Horizon 8 version 2303 now supports Hybrid Azure AD joined non-persistent instant clones using Azure AD Connect.”
Hi Brett, there’s a few links in this post: one to the release notes that specifies it, just below the quote, and also another link pointing to a VMware KB providing additional information.
Cheers