Tuesday, April 18, 2017

Is Group Policy Gonna Die? Do I have to use MDM in the Future? Interview with Jeremy Moskowitz

Hi everyone!

I believe most of my followers are wondering if Group Policy is going to be replaced By MDM or not. I am too and I have my own opinions on this which I am not afraid to share. In my last newsletter (link) I touched this topic a bit. I was honored to have Mr. Group Policy - Jeremy Moskowitz - himself contacting me and giving me his opinions on this. As he must know this better than most on this planet I asked him if he would do an interview on this topic. Oh boy was I happy when he said "Yes!"

Full Disclosure: Jeremy Moskowitz is a personal friend of mine, a 14-year Group Policy MVP and heck of an awesome guy. He teaches THE WORLD’S BEST Group Policy training (with MDM tips and tricks too!). He also runs PolicyPak software, which plugs into Group Policy/SCCM/MDM while doing amazing things. And because there is no way to shy away from it, I gave him permission to mention PolicyPak in this interview.


If you’re interested in his training and/or some insanely great Windows 10 management software, check out www.GPanswers.com and www.PolicyPak.com.


Now, on with the interview . . .


Q: What is MDM, and how is it different than traditional in-the-box management (Group Policy and SCCM)?
A: MDM stands for Mobile Device Management. It’s a new built-in agent-like “receiver,” similar to other agent-like “receivers” in Windows such as Group Policy, PowerShell, and RemoteRM, not to mention other “receivers” you might add on after the fact—SCCM, Altiris, or a zillion others.

MDM support actually started with Windows 8.1 but really wasn’t “ready” until Windows 10.

MDM requires a third-party server to be available to give MDM directives (policies) to endpoints; this occurs over XML using a thing called the “OMA-DM protocol.” The most popular MDM servers are Windows Intune, VMware Airwatch, and MobileIron. Plus, there are dozens more.
What’s special about MDM is that the protocol and “receiver” can work across a multitude of devices like iPhones, Androids, and Windows 10.

So the dream is “make one policy and apply it everywhere.” Then boom, you’re done!
It’s a nice dream, but it still has a ways to go.





Q: How do you feel about MDM in general?
A: I’m glad you asked that question. Sometimes people secretly ask me, “Hey, Jeremy, as one of the Group Policy MVPs, do you secretly hate MDM?” I tell them, “No, I don’t hate MDM; it’s not ‘hate-able.’”  In fact, MDM does a reasonable job in one key scenario: enabling users to bring or choose their own device when the IT admin doesn’t care how the machine ends up configured.
Actually, this is not only my opinion, but also Microsoft's official opinion. They've articulated MDM's strengths in this (recently updated) article about their modern management thinking:


Microsoft calls the new MDM way “modern management.” Who knows, maybe you’ll decide to trade in Group Policy for MDM to be more modern.


That sounds pretty cool, but, okay, here’s my analogy.
Let’s say you want to save money and trade in your old gasoline car (Group Policy) for a more efficient scooter (MDM). Great! On the plus side, you’ll have less payment of overhead (scooter insurance vs. car insurance), and there’ll be less to go wrong (a scooter is far simpler than a car.)


But after you do your trade-in, there are tradeoffs. As such, with your scooter, you’re not allowed to complain about not having enough horsepower or getting caught in the rain with no protection.
Remember, the scooter ISN’T meant to have a lot of horsepower or keep you out of the rain. The car is. On the other hand, the car isn’t meant to be a nimble, lightweight machine to navigate twisty sidewalks. The scooter is.  Oh, and neither a scooter (MDM) nor a car (Group Policy) is meant to do complex tasks or take you to the battlefield like a tank (SCCM) would.  These are simply different tools for different scenarios.


So if you trade in your car or tank for a scooter, you will likely save money. But there is a hidden cost: you (the admin) cannot care how the machine is configured or managed. In the MDM world, we call this “intent.” That is, you have to give up knowing what is happening end to end from a configuration perspective. Yes, there is some logging when MDM settings are actually applied, but it’s not a slam dunk to configure or troubleshoot.
As a company, and as an IT team, you have to decide if you want your Windows unmanaged (nothing at all), lightly managed (with MDM), managed (with Group Policy), and/or fully managed (with SCCM and/or SCCM alternatives). Each has pros and cons with different costs as well as security implications and pitfalls.

And, for the record, I own two cars and one scooter. (And zero tanks.)





Q: How do you see the future when it comes to GP vs MDM? On servers or clients?
A: I think you can think of Group Policy and MDM as you would IPv4 and IPv6.
Some people will have an immediate need for the new thing. Others will have no need at all. And others will have some mixed need. If clients are domain joined, Group Policy is going to be able to manage them. On this matter, Microsoft has been pretty clear: if they enable a new setting (say for Microsoft Edge or a security setting), Microsoft will encourage the team in charge of the setting to light it for use with the Group Policy channel and the MDM channel at the same time. Sometimes (and usually), the teams will do it correctly. Sometimes, there is some lag. I know, Sami, that you found an interesting setting that would fix a security hole, and the fix was ONLY MDM enabled. But with Windows 10, 1703 edition, they did what they said they were going to do, and they backported that setting to Group Policy.

So to me, Microsoft is basically keeping their promise: when they make a new setting, they Will Group Policy-enable and MDM-enable those new settings. It’s a good strategy, and it is one I really agree with.

Servers will either be domain joined or they won’t be. And they can either be “traditional” servers or Nano server. Nano has no Group Policy support. (See my take on this below.) For traditional servers, Group Policy will continue to work as expected if you want them to, or you can leverage DSC. (This is also explained below.)





Q: Is Microsoft going to give up on Group Policy?
A: I think this is the key question on people’s mind, and I have a pretty direct answer: Microsoft is not giving up on (also known as deprecating) Group Policy. They simply aren’t.
In order for Microsoft to give up on Group Policy, Microsoft has to first give up on the idea of on-prem domain controllers AND the idea of domain-joined machines—not just one idea but both.

When there are no more on-prem domain controllers, and IT admins start to say, “I won’t domain join a machine again!” only then can Microsoft think about giving up on Group Policy.

But don’t take it from me. Take it from Jeffrey Snover, who is a technical fellow at Microsoft and the person largely in charge of Windows as you know it. Here’s one of his tweets I suggest reading: https://twitter.com/jsnover/status/730104387591274496

With that being said, Group Policy for Nano is a different story when there is no Group Policy support. To address this issue, we refer to this tweet https://twitter.com/jsnover/status/730008240361103360, where Jeffrey Snover explains that on servers (especially Nano server) DSC is the replacement for Group Policy.

I do have one quibble with the current Group Policy world as it sits though. While the core is stable and not changing much except for bug fixes and minor updates, there are some areas in Group Policy Preferences that worked perfectly in Windows 7, but when Windows 8.1 (and later) came around, boom!, they stopped working. We call this a “breaking change.” The key areas that broke were Group Policy Preferences File Associations and Group Policy Preferences Start Menu settings. I’ll mention how these breaking changes can be worked around a bit later.





Q: How do you feel about Nano server not having the ability to get Group Policy directives at all?
A: After some deep soul searching—about five minutes—I agreed this was totally the correct decision. Nano doesn't need the Group Policy engine, and Group Policy isn’t the best for Nano.
On the one hand, you could argue, “If we could use Group Policy everywhere, we (IT admins) would only need to learn one thing, and it would work everywhere!”

Yep, that’s true. But it cannot be that way.

But in the same way there are different programming languages for different types of workloads (VisualBasic vs C++), there must be different management technologies for the right job (Group Policy vs. DSC).

For those who aren’t familiar with DSC, it stands for Desired State Configuration and is a toolkit built upon PowerShell to bring new servers (yes, only servers!) into the world very quickly to a desired end-all configuration. DSC does an amazing job at what it's meant to do: bring up 1 or 1000 servers and keep them configured.

Group Policy isn't trying to do that. It is the best way to manage and provide the end-user experience (look and feel settings, drive maps, shortcuts, and user-based restrictions to control panel, etc.) and client-computer security configuration.

That being said, if you have existing Group Policy settings, you’ll want to convert into DSCland, where Microsoft has some Powershell converter tools. But again, for 100000% clarity, supporting DSC on clients SHOULD NOT be attempted. DSC is for servers, servers and only servers.





Q: In your opinion, what are the biggest benefits and drawbacks when it comes to MDM?
A: On the plus side, MDM is interesting because it's the same protocol (OMA-DM) across operating systems as in Windows, devices such as Apple and Android, or whatever comes next (wireless brain-implants?!). This is similar to what Microsoft says about MDM, “It's great for devices that are constantly on the go,”(e.g., phones and tablety things).
But on the flipside, when you say, in MDM, "Force password policy to be strong," it could have different interpretations on the final device.

It's up to the MDM vendor to bring clarity to each setting and demonstrate on what device it's going to apply as well as what the ultimate experience is going to be.

Since MDM implementation is up to each vendor, there are a variety of items that you might or might not get, such as change management, reporting, backup/restore/rollback, inventory, reporting, and other things you, your IT team, and managers have come accustomed to.

By design, MDM isn’t trying to do EVERYTHING that Group Policy is trying to do. This can lead to a disconnect when people try an MDM pilot, where they will find that the things they are trying to do aren’t possible in MDMland.

In fact, people often ask us about PolicyPak Cloud AFTER a failed MDM pilot attempt because PolicyPak Cloud can literally deliver ALL of Group Policy TODAY over the Internet the way IT admin expect it to— which is expressly NOT a goal of MDM.





Q: I know PolicyPak On-Prem and PolicyPak Cloud add to what is “in the box” with Group Policy. Have you seen a change in what people ask for because of Windows 10?
A: First, thanks for the questions about PolicyPak. Here’s your beer. J


For people who don’t know what PolicyPak is, we’re an add-on for Windows 7, 8.1, and 10, which improves on the management of applications, browsers, Java, and operating systems. In other words, think new Group Policy Preferences items but for 21st century needs. We have seven components and a zillion demos on our website.
First thing’s first, PolicyPak’s policies are agnostic. That is, we work with what IT admins are already using. You can deliver PolicyPak directives using


-          Group Policy (which is typically what I show in the demos on the website);
-          SCCM, Altiris, KACE, or similar;
-          Windows Intune, Airwatch, and Mobile Iron . . . if someone has already decided to use an MDM service;  
-          Or with PolicyPak Cloud if the IT team wants no infrastructure at all (or are MSPs).
Like I said, since Group Policy’s core is staying the same but isn’t updating some areas of Group Policy Preferences to accommodate Windows 8.1/10’s changes, then we step in to fix this.

As such, we’re days away from shipping our newest component, PolicyPak File Associations Manager, which fixes this problem thoroughly. And after the summer, we plan to release PolicyPak Start Menu Manager. We have more surprises, but those are the two I’m ready to talk about before they ship.





Q: Like me, you teach a lot of people around the world. Do you see people using MDM, InTune, and BYOD?
A: In my classes, when I ask, “Are you using Intune, Airwatch, MobileIron, . . . or something similar,” on average, two hands go up every class. Then I ask them, “Are you using it for Phones, Windows, or both?” Their answer every time is “only phones.”
I'm not trying to be a naysayer or bad guy or "pooh-pooh-er." This is just what I am seeing when I ask the question. You could argue, "Well, Jeremy, you ARE teaching a Group Policy class!" Well, actually, my class covers Group Policy and MDM in case people want information on both.

Also, it should be noted that Intune is a special case and has three ways it can be used. You can do a straight MDM join; you can get the SCCM client delivered through it and manage it using SCCM console; or you can install the “fat” Windows Intune MSI client. Even with these three different ways to use it, I simply don’t get people who are actively using it to manage Windows PCs.

Again, maybe I’m talking to the wrong population, or maybe I’m somehow in my own self-made bubble and thousands of happy customers are using it. But they don’t seem to be at my classes or at special events I do with larger audiences.





Q: So what is the future of MDM and Group Policy?
A: I cannot be sure of MDM, but I can be sure of Group Policy.

By which, I mean Group Policy is a known entity, which likely won’t change much more. This is both a pro and a con. It’s a Pro because it means it’s not constantly changing under your feet, requiring you to learn a new thing every 6-10 months or guess where the wind is going to blow. It’s a con because Microsoft knows about the rough edges in Group Policy/Group Policy Preferences and likely won’t fix them. But that’s okay too. Because for every rough edge I know about in Group Policy, we’re going  to smooth it out using PolicyPak. And, technically, other companies are welcome to do this too. Group Policy is and was very extensible from day one. MDM actually isn’t extensible today at all. If Microsoft doesn’t make and then ship the moving part (called the CSP), then there’s simply no way to do it using MDM. That could change in the future. But right now, what Microsoft ships is all that you get.
MDM, however, is a moving target. Because it’s getting active development, it’s hard to know where it might go. Again, the stated goal is NOT to bring over the Group Policy “baggage” from the past, yet when you ask IT admins what they want in modern management, they actually tend to explain scenarios and settings that are almost exactly like what we already have with on-prem Group Policy.

Maybe it’s because that’s what they already know; or maybe it’s because that management style works, or maybe some other reason.

In Windows 10, 1703 (Creators Update), they enabled a lot more policy settings in MDMland. But it’s still only a few hundred.

Again, if that’s all you need, then MDM is a fine choice. But if the admin really want the full control of the device, then I don’t think MDM can dislodge Group Policy’s place in the IT world in the foreseeable future.

If you’re not sick of this subject yet or if you want more detail from a different level, I would recommend checking out my “Why Group Policy Is Not Dead Manifesto” at https://www.gpanswers.com/the-why-group-policy-is-not-dead-manifesto/ .

Thanks for the Q&A, Sami. This was fun. If people want to sign up for Group Policy (and sometimes MDM tips) at www.GPanswers.com, we’d love to have them. And if people want to learn more about PolicyPak, watch our daily webinar at www.PolicyPak.com; it is the best first step.



3 comments:

  1. Note that DSC stands for 'Desired State Configuration', it is a declarative configuration management that describes the final state you want your systems to be in as opposed to scripting individual changes from the current state to a 'better' state.

    ReplyDelete
    Replies
    1. Good catch! Thanks, I don't understand how neither of us noticed that typo. With Jeremy's approval I edited the text.

      Delete