Blogs on this so far can be found here --> https://emsroute.com/cloudnativeendpoints/
Strategizing the Cloud-Native journey is important. Many organizations have the local Active Directory (AD) as the source of truth for identities, and most systems depend on this mechanism. Most organizations are in a hybrid setup, at least for user identities.
You can still build Cloud-Native Endpoints without harming the local AD being the source of truth for the user identities. This exercise will take the device management weight off the on-prem infrastructure. AD, GPOs, ConfigMgr, you name it. But that device authentication against the domain plays a huge part when it comes to Apps, policies, Network connectivity, and other components. Everything has to be well-planned.
In the meantime, introducing Cloud-Native Endpoints doesn’t mean you will have to shut down the above items overnight.
Rome wasn’t built in one day – So as your Cloud-Native Endpoint Journey
The diagram below is a level-down interpretation of the above diagram. I want to point out the important boxes that need to be considered during the journey.
🔗PDF file to the above images can be found here
Transition from NO Cloud Connectivity to Entra Hybrid Joined State
As you can see from the above diagram, there are a few moving parts. It’s pretty easy to plan a PILOT or a POC from NO Cloud Connectivity to Entra Hybrid Joined state, as it requires the minimum effort of syncing the users (which you may already have), devices, and setting Hybrid Join for devices using the GPOs as a controlled rollout.
From that point onwards, you have 2 categories.
- If you don’t have ConfigMgr, it’s pretty easy to introduce Microsoft Intune and start managing the devices from there.
- If you have ConfigMgr today, then it’s most likely a Co-Managed setup, where both ConfigMgr and Intune manage the devices.
As the 2nd block in the diagram shows, that’s where you introduce many cloud capabilities into the end-user environment. Also, many organizations are surely in this state at the moment, where they have a strong device management process. But the fact of the matter is, it’s not cloud-native. Chances are, you have been in this state for a few years now. Maybe have forgotten about the Entra-Joined as that’s in the “long way to go” bucket, or “we are no way near making devices removed from our Local AD” argument.
Ideally, this planning is crucial because this is where you test the co-management, test Cloud Capabilities, and move the devices fully into Intune Management so you can eliminate one dependency.
Planning From That Point Onwards
Once you are in the Entra Hybrid Joined with Co-Managed state OR Full Intune, this is where you test the cloud goodness. As I mentioned earlier, this is not a last resort, but testing cloud capabilities and planning for your Policies via Intune and experiencing Entra SSO, Conditional Access Policies, etc.
What I’ve just mentioned is very high-level, as there are a few things we need to discuss, also not to mention there there can be many other dependencies according to the organization.
Next Up
Let’s discuss the Intune part specifically, as moving from a ConfigMgr setup to a Full Intune state will have many components to consider.
Discover more from EMS Route
Subscribe to get the latest posts sent to your email.
