Hybrid Azure AD Joined Login
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).
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.
Please see below for a few workarounds and/or solutions:
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.
While most of us frequently deploy new ESXi hosts, a question and task not oftenly discussed is how to properly decommission a VMware ESXi host. Some might be surprised to… Read More
This guide will outline the instructions to Disable the VMware Horizon Session Bar. These instructions can be used to disable the Horizon Session Bar (also known as the Horizon Client… Read More
Normally, any VMs that are NVIDIA vGPU enabled have to be manually migrated with manual vMotion if a host is placed in to maintenance mode, to evacuate the host. While… Read More
You may experience GPU issues with the VMware Horizon Indirect Display Driver in your environment when using 3rd party applications which incorrectly utilize the incorrect display adapter. This results with… Read More
Today we're going to cover a powerful little NAS being used with VMware; the Synology DS923+ VMware vSphere Use case and Configuration. This little (but powerful) NAS is perfect for… Read More
Today we'll go over how to install the vSphere vCenter Root Certificate on your client system. Certificates are designed to verify the identity of the systems, software, and/or resources we… Read More
View Comments
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