Most environments today aren’t 100% cloud or 100% on-prem. They’re messy, somewhere in between. Maybe you’ve still got file shares, a print server, a few legacy apps that only speak Kerberos — but you also want the flexibility, security, and simplicity of cloud-managed endpoints.
The good news: you don’t need to keep hybrid joining devices to make it all work.
The better news: you can move to fully Entra ID joined devices without breaking your old stuff — if you do it right.
This post walks through the “why” and the “how.” It’s based on real-world questions from customers, and real configurations that work.
👇 What We’ll Cover
We’re going to break this down step-by-step. You’ll learn how to deploy and manage Entra ID joined Windows devices in a hybrid environment — without relying on legacy infrastructure.
Here’s what’s inside:
- 🔥 Why copying all your old GPOs into Intune is a terrible idea
- 🔐 How Cloud Kerberos Trust lets Entra ID devices authenticate to on-prem AD
- 🗂 How to migrate drive mappings using old GPO logic (no reinventing needed)
- 🖨 What to do about printers (spoiler: they still suck)
- 🚀 How to set up Autopilot the right way — no local admin, no noise
- 🔒 How to use LAPS with Entra ID joined devices
- 🧭 How to set a DNS suffix using Intune’s settings catalog
Let’s get into it.
☠️ Stop Trying to Rebuild Your GPOs
One of the first mistakes admins make when moving to Intune is trying to recreate every single GPO they’ve ever had.
Here’s the hard truth:
Most of your GPOs are old, irrelevant, and doing more harm than good.
They were made for a different environment — one with legacy apps, old hardware, and little to no mobility. Things have changed.
Here’s what you should do instead:
- Set up a test machine
- Join it to Entra ID using AutoPilot
- Install your apps, connect to shares, test login, test printers
- Run a gap analysis — what’s missing? What’s broken?
Only replace the things that are actually needed. If you blindly try to port over 200+ GPOs from your old domain, you’ll waste time, introduce bugs, and hurt user experience.
🔐 Cloud Kerberos Trust = Legacy Access Without the Mess
So how do Entra ID devices connect to things like SMB shares or apps that expect a domain?
That’s where Cloud Kerberos Trust comes in. It bridges the gap between Entra ID and on-prem AD — letting your cloud-joined device authenticate to domain resources without being domain joined.
I recommend enabling/enforcing Windows Hello for Business aswell, during this.
That means:
- ✅ File shares still work
- ✅ Legacy line-of-business apps using Kerberos still work
- ✅ You don’t need to hybrid join or sync device objects
But here’s what Cloud Kerberos Trust doesn’t do:
- ❌ It doesn’t magically give you access to your DC
- ❌ You still need network connectivity (VPN, line-of-sight to DC etc.)
This handles identity, not networking. So if your client can’t reach the DC, Kerberos won’t do anything. Keep that in mind during planning.
My policy looks like this:
📖 The Gurus on msendpointmgr.com made this cool deep dive, it’s my go to and I definitely recommend it: Full deep dive here
A thing to note here, is that the screenshots they uploaded back in the day, aren’t up to date. Refer to my screenshot above to create the intune policy.
We’ll talk about Global Secure Access in a future post as a way to remove VPNs entirely.
🗂 Drive Mapping — Use What You Already Have
Drive mappings are often tied to legacy workflows — accounting apps, shared storage, HR tools. They’re not going away overnight.
The good news is: you don’t need to re-engineer them.
Use this tool:
🔗 https://intunedrivemapping.azurewebsites.net/DriveMapping
It takes your old GPO preferences and converts them into a PowerShell script you can deploy via Intune.
You keep the same drive letters, paths, and logic — just push it the modern way. No need to rethink the whole thing unless you want to.
It’s especially useful in transition periods when users are moving off domain join and still need access to old mapped drives.
One thing you’ll have to be aware of, is the DNS Suffix. We’ll fix that later on.
🖨 Printers: Still Awful, But Manageable
If you can get rid of printers, please do. They’re the last big blocker to a clean, cloud-only setup.
But if you’re stuck with them, here’s how to survive:
Option 1: Scripted Mapping or manually adding printers
Just map printers using UNC paths. The users can either connect to them directly via File Explorer \\PrintServer\ or map them using powershell
Add-Printer -ConnectionName \printServer\printerName
Option 2: Use RockMyPrinters
This tool gives you a way to map and manage printers dynamically, based on user/device conditions. Built for modern endpoint management. Saves you from building your own logic from scratch. This means you can make the printers available in the company portal for self-service.
Option 3: Universal Print – My Favourite if you don’t print much.
Great tool if you don’t print that much, you’re probably licensed to use it.
I know that Microsoft is working on a docker based connector, so you’d easily be able to plug in a raspberry pi or something of the like. For now, you need a windows device that can see the printers. Unless your printers support UP out of the box.
Extremely low complexity, easy to maintain and works with build in Microsoft tools. It – just works – speaking of which, it now supports MacOS devices, since december 2024.
I’ll definitely do a post on this, I just need to find a printer.
🚀 Autopilot Setup: Clean, Fast, and No Local Admins
Your Autopilot profile is what defines the device’s first experience — and sets the baseline for how it’s managed.
Here’s what I use for a clean, secure config:
- User-driven mode
- Join type: Entra ID
- User account type: Standard (not a local admin)
- Skip: privacy settings, Cortana, region, keyboard, etc.
- Optional: Add a naming template like
ENTRA-%SERIAL%
This gives you a clean slate, skips unnecessary prompts, and prevents local admin from being granted by default — which brings us to…
I recommend using a neat naming convention, for me, TechWithLudwig, TWL-%SERIAL% would be great.
Mine looks like this:
🔒 LAPS for Local Admin Access
LAPS (Local Administrator Password Solution) now works with Entra ID joined devices — and it works well, if you configure it right.
Step 1: Enable LAPS in Entra ID
This is done in the Entra Admin Center under Device Settings.
You must enable LAPS here before any Intune policy will apply.
Step 2: Configure It in Intune
Once LAPS is enabled, create a policy in Intune:
- Go to Endpoint Security → Account Protection
- Create a profile targeting Windows 10/11
- Use the following settings:
This ensures secure, auto-rotating local admin creds — with visibility in Entra and audit trails.
🧭 DNS Suffix — Important for a lot of on-prem stuff.
Some apps, especially older internal systems, expect devices to have a specific DNS suffix like corp.local or company.internal.
To set this, use the Intune Settings Catalog. No OMA-URI needed.
- Go to Devices → Configuration Profiles → Create
- Use Settings catalog
- Add DNS Client → Primary DNS Suffix
Set it to your internal domain: techwithludwig.local or whatever you’re using.
This prevents a ton of weird name resolution bugs when devices are off-domain but still need to hit legacy resources.
✅ Final Wrap-Up
Running Entra ID joined devices in a hybrid environment doesn’t mean giving up legacy access — it just means doing it better.
We’ve now configured the basics, now you’ve got a “clean slate” to develop your environment upon. Auth works, printers and mapping works.
Don’t bring the entire GPO jungle with you. Do a gap analysis. Build fresh.
Test, validate, move forward.