4. Cloud-Native Endpoints – From Config Manager to Intune – EMS Route

If you have Config Manager today and you are thinking of or planning on moving the devices and the workloads to Intune, this article is for you. If you are in that state today, chances are you have a stable (or near-stable) method of managing the devices, patch updates, and GPOs. Moving the capabilities to the cloud makes your life easier, as you know. Chances are, you have Enterprise licenses (M365 E3, for example), and you are finding ways to fully utilize them. Using the Microsoft Intune components opens the world to a lot of opportunities.

This article is a high-level overview of moving to that Intune-based solution and what things you need to look at when planning.

In a nutshell, the diagram below can be taken as a high-level idea of the process.

Understanding and Discovery of Your Current Setup

Discovery plays a huge role in mapping the current status of your environment for a successful cloud journey. This should be a collaborative effort between IT teams. Examples are the Helpdesk team, the Infrastructure team, and the Security team. I’ve added the helpdesk team because they will hear from the users if something goes wrong.

Current Config Manager Workloads

Understanding the current settings used in Config Manager is important, as they need to be recreated in Intune if you need to reuse them. Configuration settings, Compliance policies, and Endpoint protection policies need to be checked.

Device Collections – If you have the policy settings applied, the device collections will be an important factor, as that’s the boundary when creating policies in Intune. Make sure you have a clear understanding of the device group/s against the policy.

Apps

Apps play a significant part in Config Manager. Pushing apps to devices is something the IT teams are heavily depending on the Config Manager, and that needs to be carefully investigated. Some questions you can ask to make the discovery process easier.

App Types

In-house apps, Microsoft apps, and popular ISV (Independent Software Vendor) apps are some types of apps. Some apps have dependency apps and prerequisites to go in before the installation. How would you tackle that?

Win32 Apps

There are some apps that come in the .EXE format. For those, if you are unable to find the .MSI version, then you might need to use the MS Win32 App Prep Tool to convert the exe to an .intunewin file.

If you are unable to find the Install and Uninstall commands for those Win32 apps, reach out to the app vendor and most of the time, they have their documentation on silent/ unattended install commands that can be used.

Below is the process taken from this link to show you the high-level steps of converting an app to a .intunewine file.

Introducing the new Microsoft Inrtune Enterprise App Management

This is a cool new feature that will be generally available soon, so the popular (and most) Win32 apps can be easily searched and selected from an App Catalog. The best part of this is the install/ uninstall commands, detection methods will be all pre-filled and IT admins don’t need to do anything.

🔗 More info can be found here

New Microsoft App Store

A lot of apps from ISVs can be found in the new Microsoft Store app option in the Intune Apps section. With this, it is just a matter of selecting the right app and assigning it to the device or the user group. This will save a lot of time preparing apps to be able to push to the devices.

Who are the users? What Apps Can be Made Available Via the Company portal?

Some base apps need to be installed as always, but there can be apps that need to be installed depending on the user’s department or the type of work they do. App assignments can be done according to the user or the device, and can make the app available in the company portal, so it will not be installed until the user actually requires it.

Below is a snippet of the app assignment options. Uninstall is also an option if you need to remove apps from the devices.

What are the Devices?

Same as above, if the app doesn’t have a user dependency, you can use device groups and the apps will be installed on those specified devices.

For this to work and apps to be installed, Client Apps workload needs to be switched to Intune for the intended set of devices.

SOE

One of the great advancements of Microsoft Intune is Windows Autopilot. Also, this is something a lot of IT admins get the terminology wrong.

No – Itnune does not store an image to push to the devices
No – It will not be done via local LAN
Yes – The device needs to have a vanilla OS (Win 10/11) to run the Autopilot

The concept is simple. IT admin will create the configuration policies, Endpoint protection policies, Compliance Policies, Device Restriction policies, and Apps > IT admin will assign the policies and apps to the users or to devices > When the Autopilot is running, it will pick up the assigned apps and policies accordingly and will run according to the Autopilot Deployment profile and the Enrollment Status Page settings.

So, Yes – Intune requires an Internet connection and Line-of-sight access if you are planning on the Entra Hybrid Joined option.

As you can see, it’s a big jump from running Task Sequences and Imaging via Config Manager. But the great thing is the device can be SOE’ed from anywhere.

Above are the main things that you need to discover, identify, and make a plan on how to move them to the Intune side of things. This is also a great opportunity to remove what’s not needed. That being the outdated/ untouched GPOs, old apps that can be replaced with new apps or versions, etc. Also, a great opportunity to learn the ways of managing endpoints in a secure way with less hassle.

Planning for the move

Once you are done with the discovery, you can move on to the planning phase. Again, this is a well-thought-out process as this is where you do a lot of exciting work. I’ve pointed out some action items below and I will expand on them separately.

Licenses

You have to make sure at least the Microsoft Intune Plan 1 is there with the M365 Licenses. This will mainly cover the main Intune features and anything else can be covered with the Intune Plan 2 or the Intune Suite later.

Proper Network access – https://learn.microsoft.com/en-us/mem/intune/fundamentals/intune-endpoints

This is huge! The idea behind this is that the Intune-related endpoints need to be whitelisted or have proper access from your Firewall or Proxy. This is one one the main things you need to add to your planning and get the necessary teams involved for the changes. Refer this guide for the full set of Endpoints.

Get Set, Co-Managed

Co-Managed State should be a temporary state. Yes, it should be. This is where you Pilot things out and understand the behavior of the workloads. Once the Pilot is done, it’s time to get all the devices enrolled and managed via Intune.

Once the devices are set to All and Workloads set to Intune, the Config Manager dependency is pretty much gone and you can start planning to decommission the servers.

🔗 More info can be found here

Device Enrollment

As a part of the Co-Managed setup, this is the next thing you need to look at as the endpoints will enroll in Intune when you have set the necessary settings. However, the Cloud Attach feature itself gives you the option to auto-enroll the Co-Managed devices in Intune. This allows you to enroll the devices as they are presented to Co-Managed. Here you have the option of trying out for a Pilot batch and moving to All. The idea is not to add devices to the Pilot batch. Once the Pilot is done, move to All devices to be automatically enrolled in Intune.

Go Fully Intune

Get to the Fully Managed Intune Mode

As I mentioned earlier, once the Pilot is done, once you are satisfied with what you will be getting in Intune, it is time to flip the workload switches to Intune with the Automatic Enrollment set to All. As a good practice, please don’t add devices to the Pilot batch; in this way, the Config Manager will never be decommissioned. Instead of that, change the options as I’ve explained.

CCM Client Removal

Once the device is no longer managed by Config Manager, it is a good idea to remove the device from Config Manager and remove the CCM client from the endpoint so the device will not have any attachments to Config Manager.

Moving away from Config Manager is a milestone in your Cloud-Native Endpoint journey. As you can see above, there are some essential steps that need to be done before moving workloads and activities to be carried out as post move. More importantly this is achivable with proper planning and having that end-goal in mind.

Next Up

Now that we checked transition to Intune, lets discuss about Group Policy Analytics before re-modelling them in Intune