HAADJ: Stop it, you're making it worse for yourself (mostly)

HAADJ: Stop it, you're making it worse for yourself (mostly)
Photo by Elisa Ventur / Unsplash

HAADJ. A blessing or a curse for the shift to Modern Management? What if it was actually both?

This post aims to explore the benefits and issues of hybrid device management, the shift away from a Hybrid Azure AD Joined state, and the importance of setting realistic expectations for any Modern Management project while balancing the benefits of cloud-native solutions against unique business-case scenarios.

Hybrid Theory

Firstly, what does "Hybrid" even mean in this context!?

Well, back in my day (cue waving fist at the sky) the first time I encountered the word, it was in relation to Hybrid Exchange. Long before the days of AAD Connect or Cloud Sync there was a little tool called DirSync. DirSync was a simple beast (compared to it's bigger brother, FIM) and it made it possible to easily replicate your users and groups (provided you were in a single forest) up to Microsoft's new-fangled "Office 365" via "Windows Azure Active Directory" so you could start to move your most infrastructure-demanding Exchange boxes' load up into Exchange Online.

Then DirSync was replaced with AD Sync, a multi-forest version of the DirSync tool with a few more bells and whistles. It was around this time I remember the beginning of the terminology Hybrid Identity.

Then we had Azure AD Connect (three DirSync's in a trench coat) which continues to power most businesses Hybrid Identities today. But ADConnect could do something with devices: It could Hybrid Domain Join them! Imagine that! A device that natively knew about "the cloud". What a novel concept...

Fast forward a few years and the world got COVID. Suddenly everyone was working remotely and some genius decided to call this Hybrid Working, confusing the whole thing even more.

NB: I'm not an etymologist and it's bloody hard to find historical articles on the things above so I'm relying on somewhat shaky and painful memories of implementing these things over the course of time.

Anyone see the issues you may have by using the word "Hybrid" and expecting someone to know exactly which Hybrid you're talking about? Sort of makes the word feel rather meaningless, doesn't it? This particular blog post however, focuses on those Hybrid AD Join devices, and how that fits into a modern environment.

Modern Device Identity?

For a long time, the Microsoft messaging around a Modern Management journey was that HAADJ was where a business needed to be, and that's still true, to an extent. The problem here is that while getting your existing, on-prem, GPO-managed devices into a HAADJ state is ABSOLUTELY part of the journey, alongside the release of Windows 1803, Microsoft also enabled the following functionality within Intune's Autopilot deployments:

To be clear, Autopilot existed for a whole year between Win10 1703 and 1803 supporting AADJ deployments only. I can only assume that a few deep-pocketed global businesses didn't like that, and demanded less innovation and more maintenance of the status quo...

HAADJ Autopilot was touted as (and for many people I speak to is still seen as) somehow the "best of both worlds". In reality, it is far from it. It is one of the biggest scourges on transitions to Modern Management for one simple fact:

Anything still domain-joined is fundamentally NOT being truly Modern Managed!

The whole process is somehow simultaneously both intricately and poorly documented, implementation of it can be hideously difficult and even require deployment of new infrastructure depending on your environment, and it has significantly more moving parts involved, leading to serious issues using it, or in a worst-case scenario a project seen as a failure entirely. Overall, it's a rubbish user experience, a rubbish management experience, and gains you very little, especially if you're doing ConfigMgr builds.

For anyone reading this and still relatively fresh to the whole Intune/Autopilot/Modern Management thing, I'm going to link some two great initial articles rather than reinventing the wheel, but by all means go and Google/Bing, or ask on one of the great communities such as the MS EMS or WinAdmins Discord's and see what other responses you get:

In other news, it's positive to see the messaging around this from Microsoft is changing, with more articles, blog posts, YouTube videos being very clear what the MS-recommended approach is, but I still regularly see and hear people asking the same things.

Myth Busting Time!

So! What are some of those frequent myths and misconceptions around Hybrid Azure AD Join (HAADJ) vs. Azure AD Join (AADJ)? Let's start by hitting some points that come up (literally) time and time again. So much so, that I originally wrote these below points for the WinAdmins Wiki but I'm going to re-post some of the key ones:

"We need HAADJ to access file-shares on-prem!"
Assuming Hybrid Identity is configured appropriately through AAD Connect, a user account accessing a file-share via a fully cloud-native device will be able to access the share in exactly the same way as a domain-joined device would.
You would still need line-of-sight to the server either physically or via a VPN.
"We have ConfigMgr and need HAADJ to do keep using it!"
Using co-management via cloud attach and a Cloud Management Gateway (CMG), you can continue to use your on-premise infrastructure to deploy policies, applications and updates to cloud-native endpoints.
"We've got legacy apps that need us to be HAADJ!"
Partially True:
Unless the application uses device-based authentication (which is not common or a recommended practice), a cloud-native device would be able to access a web or thick-client app in the same way a domain-joined device would, and you would still need line-of-sight to the server either physically or via a VPN.
Consider publishing internal web apps through Azure AD Application Proxy and switching to SaaS versions of your software which can integrate with Azure AD.

Aren't Hybrid devices important, though?

In short, yes, very, but there are some caveats.

Posted below is a slide from a deck I put together to present at the first MS EMS Community event. It aims to high-level an approach to the whole Modern Management journey, and you'll notice the first point on that timeline is getting your existing devices into a hybrid management scenario:

That initial shift and enrolment of existing devices into a Hybrid Azure AD Joined state blows the possibilities and functionality of the cloud wide open. Suddenly you can begin to patch all your devices with Windows Update for Business, get some amazing Endpoint Analytics, understand your Office estate by enabling the Inventory over on config.office.com, and even begin to deliver apps or app updates via Intune.

For any business, that functionality is huge, and hopefully frees up enough time for an EUC team to then focus on the important stuff: Identifying and fixing those blockers to cloud-native. The difficulty here often comes with a misunderstanding of expectations, and depending on who set those expectations, it could very easily come to a grinding halt, annoyed stakeholders, burnt-out engineers, or both.

So you're saying we have to have all our devices cloud-native!?

That would be the dream, wouldn't it? That's likely what your business thinks it's end-goal needs to be, but back to that expectation-setting, there might be perfectly good reasons for a subset of devices to be anything other than on-prem domain joined, perhaps forever, depending on the circumstances!

Having recently attended the incredible MMS MOA, I purposefully initiated conversations with strangers, and chose to attend a number of sessions purely to try and get more stories and use-cases for this type of thing. Some regular themes that came up were:

  • We're a manufacturing company and we've got a bunch of desktops that run legacy and/or complicated software due to being connected to massive bits of business-critical machinery.
  • We're a hospital and have bespoke applications and/or hardware that are literally responsible for keeping people alive.
  • We're a school/university and have huge labs of computers that are all shared and all need every possible bit of software imaginable.
  • We're in military/defence and have air-gapped devices for security reasons.

Does it make sense to try spend the effort and cloud-native those devices? Almost definitely not.
Does it mean that you have to halt an entire modernisation project and try to deal with everything all at once? Absolutely not.

Cloud-native what makes sense to be cloud-native, and at a pace that works for your business.

How many of your users are 1:1 to their devices and use little more than the M365 Apps? From those above conversations, that could easily account for 75-90% of an environment. Sure, it could be way less, but regardless, even if you could only move 20% of your environment, surely that's 20% of your estate that you'd have to not have to spend time running through a ConfigMgr task sequence? 20% of your users who have a significantly better overall user experience from the point of onboarding?

So HAADJ Autopilot might be best for us then?

As much as it pains me to say it: Yes. If you don't have ConfigMgr and have some significant hurdles to tackle first, it may well be. For now, at least.

It's worth highlighting though, that doesn't invalidate the necessity to do the relevant analysis on things like User Identity, Data, Applications, etc., because things will continue to change, and it's unlikely to be an option forever. It's always best to try and get ahead of things as much as you can, rather than be surprised by them or rushed and stressed to hit a deprecation or EOL notice.

Speaking of which, did you happen to read the thing I wrote about moving to Windows 11? ;)

Windows 10 is Dead! Migrate to 11 immediately!
An exploration to why every business should consider upgrading to Windows 11 sooner, rather than later.
James Robinson

James Robinson

With 20 years of experience, James is a Principal Consultant specialising in Modern Workplace and End User Compute technologies, with a focus on Modern Management and Cloud-Native endpoints.
Brighton(ish), United Kingdom