As we all know, the cloud paradigm shifts in IT continue.  When I worked in corporate IT - heck, when I started blogging out here - on-prem was really all there was.  Active Directory, GPOs and WINS were all the rage.  Outbound Internet access was used to look at wedding photos or research TechNet about recovering from an accidental AD deletion.  Inbound Internet traffic was mostly remote users coming back into the corporate LAN – via VPN or <gulp> modem (where are my Shiva LAN Rover fans?).   

A lot has changed.  The Internet is now your LAN.  Cloud services, SaaS, PaaS, anywhere/always-on connectivity, etc. are all mainstream now. 

As I chat with enterprise customers in cloud strategy discussions, a few topics always come up once we get to the PC deployment and management aspects of that convo. 

“Should we do Hybrid Azure AD Join or Azure AD Join?”

Organizations generally have a well-developed on-prem PC deployment/management solution that includes AD-Join as a cornerstone of that process.  How does that change as we look forward?    

There are two major directions for this “join” question as we go into the future:

• Hybrid AAD Join (HAADJ) extends the existing AD model and registers AD joined PCs into AAD to allow for cloud capabilities such as device-based Conditional Access for Domain-Joined PCs.  
  • HAADJ is great for existing AD Joined PCs, but in some ways, it can perpetuate a backwards-facing ‘on-premises centric’ model and reduce (or complicate) some key benefits that the cloud offers
• AAD Join (AADJ) recenters device join in a forward-facing ‘cloud centric’ position that brings benefits today and tomorrow, on- and off-prem. 
  • Azure AD Join allows a user to natively join an approved device to your cloud directory from anywhere, without the need to contact the LAN/AD and establishes the device’s foundation for zero trust
    • BONUS – AADJ can (and should) require MFA as part of the join process
  • The integration between AD and AAD provides nearly 100% backwards compatibility for on-prem resource access from an AADJ PC
    • Typical user-based kerberos authentication, such as file-share access and printing, “just works” for sync'd AD users on an AADJ’d PC.
    • One uncommon gotcha here - situations that require machine-based kerberos authentication may not work because the AADJ PC doesn't have a computer account in the local AD (and no, 'Device Writeback' from AAD doesn't create a true computer account in AD)
  • If you haven’t guessed it yet, I strongly recommend you use AADJ for new Windows PCs, and use HAADJ to extend your current AD-Joined Windows PC estate into the cloud.    
    • Today, there isn’t a tool to migrate or transition a PC from an AD joined state to an AAD Joined state - so the preferred time to the change from AD to AAD centric is at “new device” time – PC refresh or replacement scenarios.
    • OneDrive ‘Known Folder Move’ allows you to redirect the profile folders (Documents, Pictures, Desktop) from the local device to OneDrive – that helps make sure user’s data and documents follow them when a new PC is issued
      • Redirect and move Windows known folders to OneDrive - OneDrive | Microsoft Docs

NOTE: Beyond join type, you should consider supplementing existing on-prem GPO/SCCM management by bringing Intune into the management solution, either by stand-alone enrollment or by enabling Co-management

NOTE: The Windows 10+ OS is cloud-aware and most of the “client-side” aspects of our cloud services such as Autopilot, Endpoint Manager, Endpoint DLP, etc. are built right into Windows.  That means there isn’t an agent to install/manage, and as Windows is patched/updated, that client-side code is serviced as well.    

“But we can’t do AADJ because we still rely on GPOs and AADJ PCs don’t support GPOs”

Well, it’s true that AADJ PCs won’t connect to the SYSVOL share on Domain Controllers in AD and process GPOs.  However, we’ve done a lot of work in MEM to bring 1000s of GPO settings directly to the cloud.  So, while your on-prem DCs might not distribute the settings to AADJ’d PCs, I’d bet most of the actual settings you define in your GPOs can now be defined in MEM – and delivered “over the air” to AADJ’d PCs via the Windows built-in MDM channel.

• We continue to add ‘native’ MDM settings to MEM, as well as more and more ADMX-based settings. 
  • Use ADMX templates on Windows 10/11 devices in Microsoft Intune | Microsoft Docs
• We also have Group Policy Analytics in MEM that allows you to upload a backup/export of your GPOs into MEM, which then evaluates those settings for MDM parity - and can even generate a comparable MDM policy.   
  • Use group policy analytics to import and analyze GPOs in Microsoft Intune | Microsoft Docs

“I’m intrigued … I’ll dip a toe … how do I get started?”

I propose starting with a simple ‘tabletop exercise’ to establish your key scenarios – grab a pen and a napkin, crack open Excel, go find a whiteboard… whatever gets you and your team thinking.  Line-out the typical scenarios for your current PCs.  Now, map those over to an AADJ’d PC and review/consider the gaps/exceptions. 

If you’re like me and you learn by doing, once you have some scenarios documented, roll up those sleeves and test!  I like Friday afternoons for doing alot of my learning/PoC testing/validation - hence the timing of this post.  There is no time like the present 🙂

• Setup an AADJ’d PC for your environment and see what your experience is.  Run through typical activities.  What works?  What doesn’t?  Document your efforts and results then prioritize any gaps. 
• Evaluate your actively linked GPOs for meaningful settings and get those into MEM – either manually creating policies or via Policy Analytics (the savvy-eyed reader will notice the GPMC screen shot below highlights the active/linked GPOs that I imported into my Group Policy Analytics workspace above)

TIP: Take some time to review/rationalize your GPO inventory – 22 years of GPO history likely contains some technical debt (I’m looking at you, settings defined in ‘aught-six’ for the Windows XP deployment).     

“We want Autopilot”

Autopilot is a SUPER popular capability as it allows you to deploy a well-managed “business-ready” PC to a user anywhere there is Internet connectivity.

• Autopilot for AADJ PCs is slick and works very well. 
• Autopilot for Hybrid AADJ PCs is a reality, too.  It works.  And it is supported.  It can back-haul a device into on-prem AD from the Internet.  That said, there are a lot more moving parts, timing idiosyncrasies and other orchestrations involved in Autopilot for HAADJ.  This makes our support scope very rigid and very narrow.  It is considerably more complex to setup, troubleshoot and operate than Autopilot + AADJ.  Do yourself a favor and standardize on AADJ for your Autopilot deployments; you’ll thank me later.

The Constraints of Time

• Microsoft supports both of these directions - HAADJ and AADJ - including with/without Autopilot in the mix.  However, we are limited by the clock – and we spend more time focused on cloud-centric solutions.  That's just a fact.  
• Your time is limited, too, and you’ll spend it one way or another.  You can spend it dragging ‘yesterday’s models’ into tomorrow (i.e. trying to get Autopilot + HAADJ working consistently) or you can spend it on forward-facing efforts (i.e. get your settings into MEM and validate Autopilot + AADJ). 
  • Either way, I appreciate you taking some of your time to read this post

What’s missing?

We’ve been on this modern management journey for a while now and we’ve made lots of progress, but we know the work is never done.  If you need settings that are missing from MEM, or you’re hitting significant blockers to using AADJ, drop a comment below … I’m curious - and our Product Groups (PGs) thirst for your feedback to help them prioritize their efforts.

Special thanks to Arnab Mitra and Scott Hargrove for their inputs, experiences and feedback as I developed this post.

Hilde

P.S. I bet there are still some WINS deployments out there.