Please don’t setup Intune Hybrid. Just don’t.

Note: This information is relevant as of June 2017 and may change moving forward. The cloud moves quickly and blog posts have a tendency to linger for quite some time 😊

In my role as an Enterprise Architect, I see lots of different environment configurations, and often, have to work within the confines of what I’ve been given. Customers don’t always want to re-architect their environments from scratch, even if the way they have it is far from best practice. Sometimes ‘good enough’, is exactly that.

As of late, I’ve been doing lots of work with Microsoft Intune, a rather comprehensive platform of services that focuses around configuration management of devices, along with complementary services around security and compliance. The most widely used aspect of Intune for my customers is for Mobile Device Management (MDM) which, as of the latest round of updates, has a feature set comparable to MobileIron or AirWatch making it a compelling alternative to centralize licensing, billing, and management of devices in an organization.

So far, all of these customers have also had System Center Configuration Manager (SCCM or Configuration Manager) for managing their existing computers on-premise. The natural thought then, is to integrate Configuration Manager with Intune in what is called a ‘hybrid’ configuration, so that mobile devices and on-premise devices can all be managed from the same console. I’m here to tell you why this is a bad idea, even though for several years, Microsoft advocated for it.

Before we begin, you don’t have to take my word for any of this! Microsoft has updated their own documentation here, advising customers to look towards Intune Standalone for future implementations: https://docs.microsoft.com/en-us/sccm/mdm/understand/choose-between-standalone-intune-and-hybrid-mobile-device-management

First, there are different development cycles for Intune (cloud-based) and SCCM (on-premise system). Intune can function in a standalone configuration where all configuration is done via the Intune portal in Azure, or in a hybrid configuration where it is linked with SCCM and all configuration is done via the SCCM console. This leads to situations where features and functionality are available in Intune standalone but are not available to be configured via Intune Hybrid, because the SCCM console does not make those features and functionality available.

Here’s a quick example. Let’s look at the documentation on iOS device settings for Intune Standalone, and Intune Hybrid.

Intune Standalone: https://docs.microsoft.com/en-us/intune/device-restrictions-ios

Intune Hybrid: https://docs.microsoft.com/en-us/sccm/mdm/deploy-use/create-configuration-items-for-ios-and-mac-os-x-devices-managed-without-the-client

Even taking a single section, the ‘Password’ configuration for example, there’s additional settings you can configure in Intune Standalone that are not possible to configure in Intune Hybrid. Whether these settings matter to you today is important, but knowing that the Intune Standalone features will continue to evolve faster than SCCM, at least in regards to mobile device management, may give you an indicator of which configuration you’d rather be on if you’re hoping for new features that don’t currently exist in Intune as a platform.

Second, one of the biggest issues that I run into when implementing Intune for customers in a hybrid scenario is, well, patience. SCCM, for anyone that has worked with is, is a wonderfully capable product. Truthfully, I don’t know where many of our customers would be without it! That said, SCCM is anything but responsive to a lot of actions in the system. Actions are scheduled, then run on a reoccurring basis, and in some system actions, execution times are randomized in order to not overwhelm servers or systems. How does this apply to MDM in an Intune Hybrid scenario? Well, policies and configuration made in the SCCM console need to be replicated to Intune, and then pushed out to clients. The configuration for these can be complex enough, but coupled with delay and a lot less visibility into Intune actions than SCCM admins are used to (SCCM has extensive logging, but the connection between Intune and SCCM provides minimal information), it can be difficult to know if the issue is you, your policy, SCCM, or Intune when things don’t work how you expect.

Consider, for a moment, Intune Conditional Access. It’s an awesome feature of Intune that blocks email from reaching a device that is deemed non-compliant in an environment. I have users in government, healthcare, and finance using this feature with great success, but getting it configured initially can be complex.

To get conditional access to work, you need to interact with 6 systems (if we’re assuming AD, Exchange, and Configuration Management via Intune/SCCM are all in Hybrid scenarios). A good bit of the complication is waiting for everything to sync not just up into the cloud-based systems, but then back down into SCCM where features can be adjusted and reported on. Keeping Intune in a Standalone configuration cuts down on a replication/sync cycle, and as an admin, well, it just feels faster. It also gives you a web-based interface for configuring your MDM solution, which is likely what teams are used to if they are coming from MobileIron or AirWatch.

Finally, since Intune is part of Azure, which is where Microsoft is bringing many of their new features, Intune Standalone is an environment in which admins should become comfortable. Microsoft has said in no uncertain terms that it’s moving towards Intune as its primary device management system in the long-term (See here: http://myitforum.com/myitforumwp/2017/06/23/microsoft-building-migration-path-from-configuration-manager-to-intune/) . How Microsoft will handle complex situations like Operating System Deployment (OSD) is anyone’s guess, but as more innovation is being driven from the cloud, I believe the experience in learning how to use Microsoft’s new toolsets outweighs the ‘single pane of glass’ that was once the deciding feature in determining if Intune should be stood up in Standalone or Hybrid configurations. I’ll admit, this is probably a weak point of contention today, but I can only imagine it gains relevance in the coming months as Microsoft continues to innovate.

If you take nothing else away from my experiences, know that every Intune Standalone deployment I’ve done has gone quickly and successfully. Every Intune Hybrid deployment I’ve done has been a challenge for both me, and customer, alike.

Oh? I’ve convinced you? Excellent! But wait, you’re still on Intune Hybrid and want to switch? Until recently, you’d have been out of luck. Thankfully, Microsoft now allows the MDM authority to be changed as of Configuration Manager build 1610 and Intune version 1705. I’ve done this a few times, and while it requires planning and preparation, the process is on the whole, smooth. The docs on making the change can be found here: https://docs.microsoft.com/en-us/sccm/mdm/deploy-use/change-mdm-authority

Ultimately, the choice is yours as to whether or not you implement Intune Standalone, Intune Hybrid, or move from whatever configuration you already have. Just know that after a few complex Intune Hybrid configurations, and a few simple Intune Standalone ones, I know which side I’m on 😉