Every week I’m on a conference call with customers who are using, or interested in using, SCCM and Intune/EMS.  Every single conversation finds its way into the following questions:

  1. “Should I use Intune to manage Windows 10 Surface Pro and Dell/HP laptops outside the network?”
  2. “Should I integrate SCCM and Intune?”
  3. “Can I just move all my SCCM infrastructure into Azure?”

Good questions.  Unfortunately, the answers aren’t yet fully-baked.  The answer to each is “it depends”.

But during one call in particular, we had a bunch of crusty old SCCM engineers discussing the past, present and future of the product.  This wound up in a discussion about “what would it take?” …to switch to Intune as the primary management interface, even for on-prem devices.  The gist of this was not about “eventually” or long-term, but rather, what could be dropped in our lap sooner, and make us say “oh, snap! time to reconsider!”

Anyhow, we came up with the following:

1 – Hybrid Deployments

The ability to configure application deployments in a cloud console, while directing clients to fetch the content from on-prem sources.  The reverse of cloud DPs, if you will.  The application configuration resides in the cloud, and the source content, and deployment content, are hosted on-prem.

This could be handled with the Intune client being equipped to poke for the on-prem location as a means to determine on/off prem status.  If on-prem, download the content from the on-prem DP.  Otherwise, follow the configuration (wait, or download from another source).  The goal would be to support cloud clients, mobile clients and on-prem clients, where each could pull content based on proximity, performance and least cost.

This would also span out to OSD as well.  If the WIM files, driver packages, and other bits were available from an on-prem source (via PXE/WinPE) it could work. Maybe it would require something like iPXE Anywhere, or maybe not.

2 – Expanded Deployment Types

Intune would need to be able to deploy more flexible types of instructions.  Such as EXE files with additional parameters (aka “switches”), MSI’s with MST transforms.  PowerShell scripts would be nice too.

3 – Full Inventory

This is actually two parts combined.  The first being a split inventory detection that pulls a complete (e.g. SCCM-style) WMI inventory data set from a full Windows client, but does the status quo for other clients.  The second part being a means for leveraging that extended inventory to save time/effort in other areas (targeting policies, apps, etc.)

And speaking of inventory, is there a CIM-like equivalent for mobile platforms like iOS, Android, etc.?


Granted, this is *not* enough for SCCM to throw in the towel and surrender.  But these seem to be the most-used features in SCCM which are not replaceable with Intune, yet.

If this is true, or “accurate”, then it doesn’t seem like such a tall hill to climb.  We were not entirely sober at the time, so it’s quite possible we overlooked something here.  Maybe something embarrassingly obvious, but hey.

Thoughts?  Substance or Garbage?  Let me know.



4 thoughts on “What Would it Take to Move from SCCM to Intune?

  1. We’ve got a lot of customers considering this too, and one who contemplating sccm then intune, and went with airwatch for Windows 10 management.

    You can eventually do anything you do in SCCM with MDM, but for the advanced things, it’s just much, much more work on the admin. Without an agent and maintenance Windows, you have to be very crafty.

    For instance, I’ve been able to run PowerShell scripts or installshield installs with custom switches… But if you want to do something with multiple files, you have to own pushing content first.

    For instance, consider an MSi with a msp answer file. Easy peasey in SCCM. With airwatch, there is no concept of a content source folder or package, so I first create a file action to stage the files. Every individual file is its own action (barf).

    Twenty minutes later, I’m ready to make my install. This uses the CSP Exec (I believe) to run an arbitrary command, so I run a batch file with the switches (it’s very hard to get the csp to interpret complex command lines, an running a PowerShell script? That took days to figure out! (note to self, write a blog post on it)

    Custom reporting for both still is very immature, not even the same universe as SCCMs incredible abilities there.

    You can push updates and do individual approvals, or batch approval for products and types, so it’s kind of like an ADR but again, no where near as mature.

    Still, for smaller companies interested in managing user devices, i would start with a mdm build first because you get universal management built in (works internal and external) and can manage every device in one product.

    For internal servers, I would use another management tool.

  2. One other thing, logging is absolutely incredibly garbage for both intune and AirWatch. Compared to sccm, which writes the equivalent of War and Peace every five minutes, logging in mdm can be as terse as ‘install : fail’.

    Intune is better than Airwatch but both are pathetic in comparison.

  3. I completely agree with points 1 and 2. #1 really needs to be delivered with an “alternate content provider” that can be leveraged by 3rd parties like 1E and Adaptiva. While Microsoft have started making good strides towards peer-to-peer, they are still very immature compared to 1E Nomad. And they still haven’t shown anything like the bandwidth protection we get from Nomad’s throttling capabilities. Until we can insure Intune won’t slam our network, we cannot make the move for standard office based workers.

    The ability to push multi-file software distribution packages or scripts is also a critical part of being able to make Intune operationally successful. Yes, we could repackage everything, but that would require a lot of extra headcount and risk of mis-configured installs versus using standard software manufacturer installs.

    The one MAJOR gap you missed is to fill the gap in the security baseline. Microsoft has to publish an AAD/Intune based Security Baseline similar to what they provide for GPO managed PCs. MMAT is a great tool to identify that gap. MS needs to use that against their own baseline and use the gaps as a roadmap for what additional controls need to be configurable via MDM.

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s