Azure AD is not supported. Only AD DS is supported, you can still have an Azure AD connect that links AD DS with Azure AD but the AD objects need to be in the AD DS not Azure AD.
I have struggled with this for the last couple of months as well. vBritinUSA is right when they say that it isn't supported. "Technically" not supported, rather. I do have it working in my environment. The problem is consistency with the instant clone VM's being registered. Sometimes when a user logs into a floating pool, they might be assigned a VM that didn't successfully join AzureAD. This obviously causes a ton of problems with Outlook due to the fact that a proper license token cannot be acquired if the machine is not AzureAD joined. In our case, it also causes issues with Teams. By policy, we don't allow non company assets to log into anything 365 related. So if the instant clone VM is not AzureAD joined, Teams will fail to login and tell the user that "Personal devices are not permitted". Only way I have found to remedy the issue is have the user log out and back in in hopes of getting a VM that registered successfully when vCenter provisioned it.
In terms of "how" I got it to work, the key is to make sure your Golden Image VM is not already AzureAD Joined. I have always published my Golden Image snapshots to a pool while they were domain joined. As a byproduct of that, the Golden Image was also AzureAD joined. This led me to start experimenting with leaving my Golden Image non domain joined when provisioning to a pool. I found collectively, there are less problems (in my case) in general doing it this way. I know people will debate back and forth whether a non-domain joined vs domain joined Golden Image is the "right way", but in this specific instance where AzureAD comes into play, it seems to be a requirement that your Golden Image VM is non-domain joined and not already AzureAD joined.
It's also important to note that I also had to do the following:
- Created a startup task that runs "dsregcmd /join" on the Golden Image VM
- Created a logon task in DEM that runs the same command at logon of the VM (Not sure if this is actually required but I have it for good measure)
This guide directly from Microsoft regarding this topic was helpful:
As previously stated, with all of this in place, I seem to get about 70% consistency with my instant clone VM's being AzureAD joined. The other 30% of the time end users call claiming "Outlook says it isn't activated" or "Teams says it can't sign in". And of course every time the culprit is always the VM not being AzureAD joined. Like most people, I search these forums all the time and have seen several instances of people claiming they've got it working perfectly in their environment. Not sure how, but I hope Microsoft comes up with a more reliable solution in the near future, as this does get tedious and tends to annoy the end users with the issues it causes...
I have this working in our environment currently but it is an absolute joke and I am looking to leverage any other solution to get around this.
The way I was able to get it 100% of the time is by using a pool of desktops that is provisioned completely from the get go, not using machines on demand.
I then force a sync or wait for a sync to occur into AAD, for us we get syncs at 00 or .30. I check AAD to ensure the devices are there and then force or wait for another sync to happen (cant figure out the science behind this second sync, but its needed in our environment for some reason)
Now I restart the machines from the horizon portal and when they come back up they will be hybrid joined in AAD and a user will receive their PRT on log in so they get auto logged into office etc etc. I have noticed that on user log out and vm refresh it doesnt lose the hybrid join status which is a positive.
My golden image is set the same as your by the sounds of it.
I really don't like this solution though, to do maintenance is a chore of a task if you want to hit that 100% joined status.