Back in 2016, I wrote a lengthy blog on application deployment options in SCCM (System Center Configuration Manager). At the time, I started the blog stating that every client I worked for in recent times was either already using SCCM or migrating to it. It is now 2022, and SCCM has become MECM (Microsoft Endpoint Configuration Manager) and is utterly dominant in the enterprise.
At this point in time, I believe we are in a transition period caused by the switch to a remote workforce. We now require enterprise management products suited to managing devices in the office and remote. While MECM still has prominence in the enterprise, we are now trending toward cloud-native solutions or at least towards using the cloud attach feature for MECM to bring a cloud component to their efforts.
MECM and Intune
In the 2016 post, I said that Intune was NOT the best Mobile Device Management product on the market, and I believe you could still make a strong argument for that case today, BUT Intune or its new off-shoot, Microsoft Endpoint Manager, is quickly becoming as prevalent in the MDM space as MECM is in the software deployment space.
Already dominant for managing mobile devices, it makes sense to use MEM to manage physical endpoints sitting remotely in end users’ homes. Microsoft has now tightly integrated Intune into their cloud DaaS offerings with an option to auto-enroll Azure Virtual Desktops and Windows 365 Cloud PCs for all your cloud desktop management needs. This makes Intune/MEM an essential tool for managing pretty much all devices in today’s enterprises.
If you look at the Microsoft Endpoint Manager console, it looks familiar, while previous iterations of Intune had a starkly different web UI than the SCCM Console. MEM looks and feels a little closer to what we get in MECM with the sidebar options and some of the features even extending to the application level. I will get to those shortly.
In 2016, I pointed out that organizations would provide role-based access to various teams in IT, not just the desktop team, to allow them to do patch management for their machines, e.g., Citrix team, Exchange team, etc. Most organizations are still partly tied to their own on-prem data centers, so patch management with MECM is still heavily used for this purpose.
With that said, Microsoft just launched the Autopatch service for those with Windows E3 or E5 licensing. Autopatch is a cloud service that will automatically manage patches for your organization’s devices. It will sort your machines into different rings to stagger patch deployment and obviously deploy the patches to your devices. If you patch with MECM today, like me, you will probably read that and think that it is kind of cool but no big deal! Managing my department’s device collections and ensuring the Automatic Deployment Rules run as expected isn’t a pain point. The big pain point of patching and what gives Admins heartburn is that patches tend to break things!
The good news with Autopatch is that if a lot of customers subscribe to it, there will be a huge pool of devices for Microsoft to pull data from. Autopatch will bake in some intelligence to protect customers from patches breaking things. For example, if a patch is found to cause problems on a certain model of Lenovo laptops, the patches will not be deployed to those devices. Essentially, a problem for one person is fed back to the service, preventing others with the same type of environment from experiencing the issue. Kind of cool!
There are other cloud patch management services also available from Microsoft, and they have added a 3rd party patching catalog to MECM, which was a blind spot for the product for many years. Sure, you can pull patches for Windows and Microsoft products, but everyone uses products from other vendors, so what about those? Patching 3rd party products is very important. Personally, I feel Patch My PC for 3rd party product patching is still superior.
Over time, I think services like Autopatch and the other cloud-based patching services will start to erode MECM’s customer base, particularly for desktops, but let’s watch this space!
Security and compliance have seen vast improvements in MECM but even more so in Intune/MEM. With Intune being an MDM, device compliance and conditional access are at the core of what it needs to do, but as Windows Defender starts to gain market share for security in the enterprise, management of the AV is an important feature, as is the management of the firewall on remote devices. MECM now even supports configuration for advanced security products like Application Guard and Exploit Guard.
For years, Azure Active Directory lacked a proper counterpart for on-prem Group Policy. Today, modern policy settings are available, and Microsoft has included some security baselines out of the box. For example, if you want to deploy Windows 365 Cloud PCs, there is a security baseline you can deploy to secure those desktops, or you can, of course, customize it to what you prefer. At the time of writing, there are still a lot of policies you set with GPO today that do not have an equivalent modern policy, so it is a work in progress. You will feel this pain even more if you regularly work with vendor-supplied group policy templates.
If you find yourself hindered by the lack of group policies, I strongly recommend you check out PolicyPak Cloud to fill the gap while you move to the cloud.
Application Packaging and Deployments in MECM
My previous blog did not cover the Windows Installer through MDM option, but it has been available in SCCM/MECM for some time. Before its introduction, you could only deploy the mobile compatible package types (e.g., .apk, .ipa, etc.) to your Intune managed devices via SCCM with Windows Installer through MDM, but now you can also deploy MSI packages to your Intune managed devices from within MECM.
More noteworthy is the introduction of the MSIX options, which were announced to the world back at Microsoft BUILD in 2018 and represent an opportunity to move to a modern container format for your applications. If you are familiar with App-V, you will notice the MSIX packages contain a virtual file system as App-V did. The registry handling is a little different than App-V, and initially, by design, there are several limitations with the format meaning fewer applications work in the MSIX format than in App-V.
I still have high hopes for MSIX in the future, and we have recently seen more vendors, such as Mozilla Firefox, make their products available in the MSIX format. If they can continue to increase adoption at the developer level, MSIX could be a success, but four years into its existence, it still has a relatively small presence. From an IT Pro perspective, the barrier to entry for MSIX is still a little too high because not every app will work with it.
When I drafted this post, I was on a work sabbatical. I now work with Numecent, which makes a container management platform that supports App-V, MSIX, and its own format: Cloudpaging. The great thing in terms of container support is that you can deploy your existing App-V packages, and as vendors provide more apps in MSIX, you can deploy those too. For everything else, you can use Cloudpaging. If like me, you like how easy Cloudpaging is to use, you can use that for most applications.
Application Packaging and Deployments in Intune/MEM
That brings me back to MEM. You will see a lot of the same package types supported in MEM, but what you won’t find is App-V. There is no native support for deploying App-V with MEM. You can deploy MSI and MSIX. In fact, you can deploy MSIs in a couple of different formats – Win32 Apps or Line of Business Apps. Line of Business Apps can be used for some of your very basic MSI packages with simple command line arguments.
Win32 Apps extend the package options for your traditional MSI and EXE packages and even provide some features you are familiar with from MECM, like Detection Methods. The way I think of Intunewin is that it is an advanced wrapper for packages deployed in Intune. If you are deploying traditional apps in Intune, you should really go to the effort of using the Prep Tool via the Command Line and convert them to Intunewin.
Having said that, I never really enjoyed deploying apps with SCCM/MECM. It had a relatively high failure rate due to the complexity of the infrastructure involved when I used it in production environments. Our SCCM client devices would refresh every hour, which sometimes meant app deployments could take 2+ hours to reach all devices in the targeted collection and often much longer. Intune or MEM so far hasn’t really improved on how long app deployments take. In fact, it may have gotten worse for net new deployments.
The behavior I consistently see is that net new deployments take anywhere from 15 minutes to 24 hours to complete. The larger the package, the longer it seems to take too. I would guess that may have something to do with replicating the package to the different cloud Distribution Points used by MEM. This is another reason why Numecent Cloudpager has been of such big interest to me.
Clearly, we are in a period of transition with more of the tasks we typically manage from MECM getting a modern alternative. I didn’t even get into all of them, e.g., Autopilot, but much of this change has been driven by the mass adoption of Work from Home. It is led by necessity. This is not a case of products looking for a problem to solve but rather a clear and present challenge being faced by all enterprises in search of solutions.
Suddenly the cloud is not some scary prospect that enterprises leverage selectively. It is becoming a must with the remote workforce, global chip shortage, general supply chain issues, and more. It seems inevitable that more will be accomplished from Microsoft Endpoint Manager in the future, but in the short-term, MECM still has a place in the enterprise as not all features are available in MEM or a cloud alternative yet, but all signs point to greater growth in cloud and hybrid solutions.