Azure Hybrid Join...

[rnapiza]

Has anyone successfully hybrid joined with Azure AD with Instant Clones?

[vBritinUSA]

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.

Preparing Active Directory

[curtistcreps]

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:

Device identity and desktop virtualization - Azure Active Directory | Microsoft Docs

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...

[MattSyme]

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.

[curtistcreps]

I know it's been a little over a year, but I wanted to follow up on this with the permanent solution that I have working in our environment. Most of what solved the issue was related to the new Computer Environment Startup and Shutdown tasks settings in DEM 2106. Though I know not everyone uses DEM as a profile manager, in the event you do it should help you out. 

Originally, I was relying on normal group policy to ensure successful AAD joins. I accomplished this by using startup and logon scripts that utilized the dsregcmd /join command. After upgrading DEM to version 2106, I started to utilize the Computer Environment ADMX settings to move away from normal GPOs where I could (logon times were still not nearly as good as they could have been). In the process of doing so, I discovered the Startup and Shutdown tasks. I created a Startup task that includes dsregcmd /join and a Shutdown task that inlcudes dsregcmd /leave. I also for good measure still have a logon task that runs the /join command, 

After implementing these rules, I would clear out a large number of instant clone VMs at once from a test pool whilst simultaneously checking the Devices section of our Azure tenant. Sure enough, once the VM's were deleted, so were the devices in Azure. Once the VM's started to start up, they all were registered again with a valid timestamp and ID. No duplicates neither! I could confirm when logging in / out of VMs with a test account that each time dsregcmd /status showed that the machine was AAD joined. The only thing that still seems a bit off at times (but not near enough for it be a major issue), is that there are times where the machine is registered but the PRT for the user does not roam at logon correctly, which occasionally invokes a logon to Office 365 / Teams. 

As I mentioned before, this isn't really helpful for those not using DEM as their profile manager in Horizon. But if you are, I strongly suggest giving this a try. Much more reliable, no more duplicated Azure objects, random non AAD joined logins, etc. 

[Pyrosax]

@curtistcreps  - Just came across this post - and realize it is a bit dated- as we are dealing with this particular issue now.  Until now we have had persistent VDI and are in the process of moving to Non-Persistent Instant Clones. We are currently piloting our configuration and it has come up recently. After realizing our golden image was Domain-Joined and Azure AD Hybrid Joined we started to have issues a few weeks into our pilot.  I've worked to remove the Golden Image and any Image Publish Computer Account from Azure AD Hybrid Join process so they do not interfere with published computers. 

I was reading your post that you were able to solve by incorporating startup and shutdown tasks that perform the dsregcmd /join  & /leave process.  We have developed a similar process that performs this during the machine provisioning by using the batch file in the Post-Synchronization Script processing.

I've been unable to have the same success as I do not see the devices instantaneously create in AAD. I do see the on-prem AD DS computer object get updated with the "userCertificate" attribute and after AD Connect runs (every 30 minutes in our environment) the object is synchronized to Azure AD. Only then, and after performing a Recover on our pool, does the AAD Object update with a timestamp and PRT.

I'm curious if you can or willing to share what kind of settings your AD Connect/AD FS settings might have or if you had to do anything particular that allows for that instantaneous object creation in Azure AD.  I do not manage  our Azure or AD FS settings and have been trying to provide this information to our Admin team who does.  Any information would be welcomed and appreciated.