The Ultimate GPO to Intune Guide

Taking your first leap from on-premise into Intune and not sure where to start? This blog aims to provide some practical tips and tricks to help you on your way!

Review Your Existing Policies

A question to you (though it's rhetorical, this is a blog after all):

How old are your GPO's, and what do they all do?

If you don't know the answer to either of those, then before you do anything else, start a process of understanding where you are right now. Export them, do some analysis, maybe even go check a device to see if it's even doing what the policies say they're supposed to be doing?

Let's set a brief scene and see who can relate:

When you joined the IT team at the business you're at, there were a number of Group Policies that already existed. You may have been involved with adding some since then, but all that stuff that was there when you joined is still there.
Those policies were implemented by someone, let's just call him Steve (sorry to any Steve's reading this), that retired last year. Steve was oddly protective over his environment and didn't let anyone really touch things. He also left precisely zero documentation on what that stuff is when he went. The decisions that went into creating those policies all those years ago have been lost to the depths of time.
Weird, on looking at them, there's some security filtering applied to most of them. Seems Steve never had them applied to his device...

And now you want to just drag that stuff into your new tool?!
Which leads neatly onto the next thing on the list...

Avoid "Lift-and-Shift" at all costs

For the love of sanity - Don't you dare. Don't even think about it.

Why oh why would you want to drag along the archaic, scraggly tendrils of tech debt from your on-prem environment to your brand new management tool? Honestly, all this achieves is prolonging the agony and further drawing out the process of getting rid of the stuff that's no longer needed or straight-up not necessary.

Now that's been said, be aware that not everything in GPO exists in Intune Policy.
If you're a heavy user of any of the following...

• Group Policy Preferences
• Registry Settings
• Printers
• Drive Mappings

... then you're likely going to have a rough time. None of these things are necessarily insurmountable, but they'd certainly take a huge amount of engineering time to essentially re-engineer them into scripts/remediations or Win32 apps (or a script wrapped as a Win32) to do the same things.

Some sit on a sliding scale. Have relatively simple, static drive mappings to some legacy file shares? Import a simple ADMX template and be on your way. Have a complex DFS share with 650 entries intricately configured via GPP? Yeah.... Sorry.

Utilise Available Tooling

While blindly throwing everything across is generally considered as a bad thing to do, Intune does have a built-in tool available to help you on your quest: Group Policy Analytics.

The premise is simple. Export your GPOs to XML, upload them into GP Analytics, and quickly and easily see how much of that GPO is supported in Intune.

There are a number of things to be aware of before using the tool though:

• Don't expect 100% compatibility. As mentioned above, not everything that's in GPO is supported.
• If a setting says it isn't supported, it doesn't necessarily mean it's not supported. While the tool does an okay job at mapping GPO to CSP, some CSP's just work differently and don't map automatically.
• Don't be tempted to just hit the big shiny "Migrate" button. Did you not just read my previous points!?

For all its flaws, it can still be incredibly useful to help you with reviewing your existing policies and to work out what pain points you might end up having.

That being said, if you're keen to start from scratch but don't even know where to begin, you could always take a look here for some inspiration...

GitHub - SkipToTheEndpoint/OpenIntuneBaseline: Community-driven baseline to accelerate Intune adoption and learning.

Community-driven baseline to accelerate Intune adoption and learning. - GitHub - SkipToTheEndpoint/OpenIntuneBaseline: Community-driven baseline to accelerate Intune adoption and learning.

GitHubSkipToTheEndpoint

Use the Settings Catalog (Mostly)

This is going to make a painful tip, because Intune has a bit of an unfortunate problem with some tech debt of it's own, but it is getting better.
Let's say you wanted to create a policy to configure a policy for BitLocker. Where would you do that?

• Devices>Windows>Configuration>Templates>Endpoint Protection
• Devices>Windows>Configuration>Templates>Administrative Templates
• Devices>Windows>Configuration>Settings Catalog
• Endpoint Security>Disk Encryption>BitLocker
• Remediation Script?!

Or how about Windows Hello for Business?

• Devices>Windows>Windows Enrollment>Windows Hello for Business
• Devices>Windows>Configuration>Templates>Identity Protection
• Devices>Windows>Configuration>Templates>Administrative Templates
• Devices>Windows>Configuration>Settings Catalog
• Endpoint Security>Account Protection>Account Protection (Preview)
• Devices>Windows>Configuration>Templates>Custom OMA-URI!?

The above is a somewhat painful reminder of Intune's past, and a result of what was available at the time and/or what certain people thought was the best way to do it. But things change over time. In the cloud, nothing is constant. Unfortunately some of these can't be removed as I imagine they're needed for legacy/backward compatibility reasons, but I personally think some of them should be hidden in the GUI, to stop people creating new ones so easily.

This is something I'm hearing more and more from people new to Intune trying to do this stuff for the first time, and I'll concede that it's really frustrating. Almost as frustrating as the answer to "Where do you set things?":

So I'll break my recommendation down into two (and a half):

1 - For anything to do with Endpoint Security (Encryption, Firewall, LAPS, Defender for Endpoint), use the Endpoint Security node. Most of those policies are just specially curated Settings Catalog policy on the back-end, but kept together in a neat place.

2 - For everything else, use the Settings Catalog. The interface is better, reporting is better, you get the ability to use Filters... It's just better.

2.5 - For a few, niche use-cases (Certificates, Shared PC), you may need to use one of the older templates. Use these as a last resort!

Testing, Pilot, and User Acceptance

Never forget the 3 golden rules of IT:

• It was (usually) DNS
• Don't schedule changes on a Friday
• Do not yeet stuff directly into production

I have far too many conversations with people that go like this:

"I've configured x and now it's causing problems across all our devices"

"What testing did you do, and what were the findings before you assigned it to all devices?"

"I dunno, it seemed to work fine applied to my device so I thought it'd be okay."

"Yeah that's not quite as simple as you think and you're going to have to do y"

*Shocked Pikachu*

Just to clear things up:
Applying something to just your device isn't an adequate test.
Applying something to devices belonging to the IT Team isn't an adequate test (IT people are surprisingly unphased by weird behaviour and we naturally work around it).
Applying something to a couple of random devices in your environment and not having any support calls from those people in 24 hours isn't an adequate test.

The only appropriate level of testing is planned, multi-phase testing which ideally involves key users from around your business, ideally those who use different line-of-business applications, ideally across multiple device types, but most importantly, actively engages those users to capture feedback and ensure that any issues are identified and remediated prior to a production rollout.

Beware the Dangers of Mixing Management Planes (aka "You gotta keep 'em separated")

I can already hear the gears trying to work out how to "switch" your policies from coming from GPO to instead coming from Intune. Word to (from?) the wise:

Avoid it.

Nothing remotely good will come from you ripping out your GPOs from under your devices. Trust me.

Part of the problem with years of tech debt is that there could be devices out there that haven't been refreshed or even seen IT in potentially years. Remember that script our loving protagonist Steve pushed out to fix a weird issue a while back? Unfortunately neither does anyone else. Your devices do though.

Unfortunately that script manually changed a bunch of registry keys. Registry keys which now happen to be tattooed. Even policies which aren't supposed to tattoo can't be guaranteed to have removed themselves cleanly.

"Oh but what about that whole MDMWinsOverGPO thing?"

Ah yes, ControlPolicyConflict, or "The Devil in Devil's clothing" as you may as well call it, though that frankly makes it sound more appealing. A policy widely known to misrepresent a solution to a problem you can actively avoid.

There was a time where it was the default solution. That time was about 2018. Intune and Windows CSP has come a long way since then and it doesn't work nearly as often as you'd expect. Trying to configure Firewall? Doesn't work there. Defender? Nope. WUfB? Don't even think about it.

Sure it might be useful on a rare occasion, but it's a much better idea to just not corner yourself to begin with.

Keeping things separate is going to likely save you A LOT of headaches.

Don't Hybrid Autopilot

Sure this blog isn't specifically about Autopilot, but let's be honest, most people's initial interactions with Intune are usually to do with them wanting to (or being told to) improve their device deployment strategy.

I've written about this specifically before, but the it's recently been reinforced in the official docs:

Aim to deploy new devices as cloud-native. Some of those issues mentioned above cease to become issues when you do this. Can't accidentally mix GPO & CSP on a device that's not joined to your domain!

It also doesn't feel like one of my blogs without me mentioning it :)

A Summary - AKA: How To Win!

1. Review existing policies - You can't go somewhere without knowing where you are right now.
2. Avoid lift-and-shift - While starting fresh might be painful in that you have to front-load a bunch of work, it will make things easier in the long-run
3. Utilise available tooling - There's some handy stuff built into Intune to help you, use it to your advantage, but don't use it as your crutch.
4. Understand where to create policies - If it's got a section in Endpoint Security, put it there, otherwise Settings Catalog if you're not requiring something niche.
5. Testing is critical - You don't want to be the one responsible for bricking your CEO's laptop, ensure you've got a robust, ring-driven testing process.
6. Don't cross the streams - Take great care if applying Intune policies to GPO-managed devices. If something isn't working, it's unlikely to be Intune's fault.
7. Build new devices as cloud-native - Getting here takes work, no doubt, but it's worth it.

And I'll add a last one: There's plenty of help available out there. The official MS docs, while sometimes frustrating to find have all the information you need. But if you get stuck, head over to the MS EMS Community or WinAdmins Discord. We got 'chu.