The “Why Group Policy is Not Dead” Manifesto

Mar
24
2016

If you thought only crazy people wrote Manifestos, then call me crazy.

Yes, I’m crazy for Group Policy, and I also get a little crazy about Group Policy’s misunderstandings and misunderstood place in the modern “mobile first, cloud first” world Microsoft has in mind and where might all go someday.

In this manifesto I get to talk about something that’s really, really, really been bothering me (and hence, making me crazy enough to write a manifesto.)

That is, I cannot tell you how many times IT Admins like you have walked up to me, and with great concern on your face asked me something like:

  • “A Microsoft rep told me that Group Policy is dead. What should I tell my boss, and what should I do now?”
  • “Is Intune/ MDM trying to replace Group Policy?”
  • “Why do I need Group Policy if I’ve also got SCCM?”
  • “Do you think Powershell and/or DSC (Desired State Configuration) is replacing Group Policy?”
  • “Will Azure Active Directory be the death of Group Policy?”

Finally, from the topmost ranks of Microsoft, they have officially come out and expressed something I’ve been saying forever:

Group Policy is NOT dead.

And, more importantly, it’s MORE IMPORTANT than ever when it comes to Windows 10.

Here are the blog entries from the top ranks at Microsoft, and then immediately following is my analysis and guidance for you, my fellow IT admins:

From Brad Anderson, Corporate Vice President, Enterprise and Client Mobility:

https://blogs.technet.microsoft.com/in_the_cloud/2016/03/23/clear-simple-guidance-when-configmgr-and-intune-should-be-used-with-windows-10/

The actual blog post which is housed on the Windows Intune blog:

https://blogs.technet.microsoft.com/microsoftintune/2016/03/23/the-path-to-modernizing-windows-management/

Here’s the main quote from the Microsoft-written blog… which you can take to the bank:

Group Policy is the best way to granularly configure domain joined Windows PCs and tablets connected to the corporate network using Windows-based tools. Microsoft continues to add Group Policy settings with each new version of Windows.

And, if we look at the flowchart Microsoft provides, it’s clear as day.

win10mgmt3

Let me use my red marker, and highlight the most common scenario for Windows PCs on the planet today and the foreseeable mid-term future:

domain-joined-GP

This becomes a very, very simple “If domain joined, then use Group Policy” decision tree. And that represents about 98% of the Windows PC systems in the world today. Maybe 99%.

To continue, let’s break this down, step by step, and use the following questions to help others decide if Group Policy is dead or not:

  • Do you have domain joined Windows PCs and tablets? You do? Then you should use Group Policy, which is the best way to manage them.
  • Do you need to granularly configure settings? You do? Then Group Policy is the best way to do that.
  • Are you considering (or already moving to Windows 10?) You are? Then Group Policy is there to help you manage these new settings which are only available in Windows 10.

Look, I get it. It’s a confusing “landscape” of tools out there from Microsoft now to manage Windows machines.

To be clear: It’s not that I have love for old and aversion for new. For me, it really is “the right tool for the right job”. If, that “right job” is to manage and configure domain joined Windows PCs, then the “right tool” is Group Policy. And remember, it’s not me saying this, it’s Microsoft:

Group Policy is the best way to granularly configure domain joined Windows PCs and tablets

Group Policy has the most settings, the most ability, most flexibility and granularity, comes in the box, works when you log on and/or reboot, has reporting, tooling, guidance, third-party extensibility and it usually JUST WORKS as expected – across millions of PCs, millions of times and countless changes and updates a day.

This is why Group Policy is the BEST WAY for domain joined Windows PCs.

Okay then: So what are the other management tools that Microsoft has, and what are they “best at”? Microsoft has a huge variety of ways to manage Windows devices. In fact, so many, that I must deliberately omit some in this analysis for fear you will fall asleep and not make it to the end.

So, here is a brief overview of the most popular Microsoft-provided Windows management tools and what they are BEST at. I’ll cover SCCM, Intune, PowerShell & DSC and Azure Active Directory.

SCCM at its best

SCCM is best at:

  • Deploying the OS
  • Deploying other software to the PC
  • Performing inventory
  • Patching and Windows updates for the OS
  • Reporting

Yes, yes, I know: SCCM has lots of OTHER features too, but this is where SCCM is BEST.

Can SCCM deliver a registry setting which would be similar to a Group Policy setting? Can it copy a file down to the desktop, similar in function to a Group Policy Preferences setting? Yes, SCCM CAN do these things. But is it the BEST tool for doing these things? I would argue no; it is not the BEST tool to do granular policy-based management.

SCCM is awesome at what it does, but it’s not trying to overtake Group Policy.

Side note though: Just to muddy the waters a little bit with SCCM, there are some pre-baked functions which specifically overlap with existing Group Policy settings. The ones that come to mind are Power Management settings and Folder Redirection settings. In my opinion for these settings, pick one strategy: Group Policy or SCCM, because it becomes hard, almost impossible if you’re using multiple management technologies to manage the same settings. I’ll talk a little more about this “management overlap” problem toward the end of this manifesto.

Microsoft Intune at its best

Microsoft Intune is best at:

  • Managing phones (iOS, Android, Windows Phones)
  • Managing some aspects of Windows PCs
  • Getting you some ability to manage Non-Domain joined machines
  • Letting people use their own devices to access corporate data

To be clear, Intune has two ways it can manage devices. One way is called the Intune client. And like SCCM it has to be installed on the endpoint to pick up directives. As you might imagine the Intune client (like the SCCM client) can only be installed on real Windows PCs and not, say phones.

But what if you don’t want to install anything at all on your endpoint (or in the case of iOS, Android, or Windows Phones? Well, you don’t need too, and for that, you get some, but not all benefits.

Intune (or similar 3rd party tools like Airwatch or MobileIron) can all use the same “receiver” to perform their newest directives. That receiver is called MDM: Mobile Device Management client.

The MDM client (also known as the MDM platform) is a “cousin” and is similar to Group Policy; because like Group Policy, the MDM client is in the box (for Windows 10) and can receive directives, kind of like Group Policy does.

Okay then, what makes MDM different than Group Policy? Let’s go back to the Microsoft-written blog entry for the quote:

The MDM approach calls for settings that achieve the admin’s intent without exposing every possible setting. In contrast, Group Policy exposes fine-grained settings the admin controls individually.

There you have it.

MDM is good for sweeping ideas (also known as Intent), but not stellar at fine-grained settings management.

So, what is “Intent” (MDM) versus “Fine-grained settings”(Group Policy) mean?

Intent means that you might want something to be generally secure (aka VPN settings, Mail settings, Password length), but you really don’t care (or perhaps even get a chance to KNOW) what is happening under the hood. So when you want it done, across multiple operating systems, and don’t care HOW it’s done, then MDM works fine. It’s setting the settings (one, two or a zillion) but you don’t have to particularly know what.

I can see where that’s good for some administrators, but totally frightening to others.

So what is MDM BEST at then? Well MDM is all XML based, which means its directives are very lightweight and can be sent and received over low bandwidth conditions like cellular networks. So as the blog entry says:

This makes MDM the best choice for devices that are constantly on the go.

Like a phone.

But for a full Windows PC, if you want more granular management: MDM isn’t the best, Group Policy is. Here are some for-instances:

  • You cannot drop a shortcut on a Windows 10 desktop using MDM. You can using Group Policy.
  • You cannot rename the local Administrator on a Windows 10 desktop using MDM. You can using Group Policy.
  • You cannot map a printer on a Windows 10 desktop using MDM. You can using Group Policy.
  • You cannot prevent access to specific control panel applets on a Windows 10 desktop using MDM. You can using Group Policy.

Okay. This gets really confusing really fast, so try to stick with me. Because Intune can use the Intune client OR the MDM client you actually get a different set of functions and possibilities depending on which client you use.

In some cases, using the Intune client, Intune is trying to manipulate the exact same settings that would also take effect using Group Policy. The ones that come to mind are Firewall settings settings.

But Intune’s future is to be reliant upon the in-box MDM client and not the installable Intune client. And, since MDM isn’t trying to overtake Group Policy’s granular functions that means, by definition, that means Intune isn’t trying to overtake Group Policy.

Therefore, as a side note, since Intune (and tools like it) aren’t trying to do Group Policy, I often get the question of “How can I deliver real Group Policy settings to my ‘constantly on the go’ Windows PCs”. As such, there are three viable options:

  • Option 1: Ensure your people in the field use a VPN and connect consistently. Group Policy works perfectly thru VPN and will deliver on-prem Active Directory GPOs to your “constantly on the go” Windows PCs. Of course, this means that users need to initiate that VPN connection; and that could be problematic.
  • Option 2: Extend your corporate network to the Internet using Microsoft DirectAccess. DirectAccess extends your intranet OUT to the Internet (but in a secure way.) DirectAccess is only available for Windows Enterprise edition, and can be a bear to set up. People I’ve talked with who have DirectAccess set up and working really love it. But they won’t talk with you about their deployment experience until AFTER you’ve got two beers in them.
  • Option 3: PolicyPak Cloud (from my company PolicyPak Software) will take any Group Policy setting, let you EXPORT it, then upload it to our PolicyPak Cloud service. Then client computers automatically download and perform your directives. Not to brag, but “It Just Works.” And it works also for non-Domain Joined and Domain Joined machines. More information, demonstration videos and a free trial, check it out here.

Please don’t think I’m not “Pro Intune”. I am Pro Intune, for what Intune does best. It has an excellent Company Portal ability which enables self-install of applications to Phones and PCs, auto-enrollment of Phones, protects access to resources like Exchange mail and other corporate data.

But granular management of domain-joined Windows PCs? It’s simply not the MDM-platform (and by extension, Microsoft Intune’s) best strength. What is interesting though, is that the very logical thinking behind MDM settings will increase Group Policy’s own set. In other words, when a team inside Microsoft wants to MDM-enable a setting, the goal is to do their best and also Group Policy-enable that same setting in Windows 10. So, thanks MDM team for rising the tide to lift all boats. That being said, there is no goal to back-port 5,000+ Group Policy settings to MDM but increase reach as needed.

Side note: You can marry on-prem SCCM to a Windows Intune subscription, which gives you the ability from your on-prem SCCM to deliver MDM settings to your MDM-enrolled devices. That’s nice if, say, you have 10,000 on-prem PCs you want to patch using SCCM and want to use the same console to deliver an MDM setting like “Use Strong Password on my Phones.”

Powershell & DSC at its best

Powershell is best at:

  • Complex functions which require logic and error handling.
  • Configuring items which require a “method” (WMI, COM, API).
  • Reading one value and then consequently writing another value.

DSC (Dynamic State Configuration), a function of PowerShell is best at:

  • Bringing up a zillion similar servers, to a set of specific specifications.

Powershell and DSC are ludicrously powerful. But PowerShell is not meant to make ongoing configuration changes on your endpoints. And DSC isn’t not meant to declare state for Windows endpoints aka Windows 7, 8.1 and 10). DSC is for SERVERS; and doesn’t have the ability to target computers in the same way that Group Policy does nor does it have the same function set, nor is it TRYING to be a GP replacement.

May 10th, 2016 update.. So this caused a little bit of a stir on Twitter when Jeffrey Snover, Technical Fellow at Microsoft (and father of Powershell and DSC) said the following… “Desired State Configuration (DSC) is the replacement for GP – it provides better semantics for server scenarios.

jsnover1a

But he quickly clarified and honed his statement.. which makes total sense… “Group Policy is very well suited to client scenarios which is why you saw a big set of new GPs for Win10″

jsnover2

If I can be so bold as to interpret Jeffrey here, what I believe he is saying is that there are some tools which use Group Policy to configure servers today.. and they stink.. and I agree. Those two tools would be:

Those tools try to tell servers how to be more secure and they use GP as the transport to get those directives embraced. But they stink. And DSC is a better choice for telling servers how to get stood up and be secure.

Moreover, if you’re looking at Nano server, there is no GP client (receiver) in Nano server. Which for me, is totally fine. Because, again, DSC is better for Servers and not clients. For more information on this, see this article from Zach A. from the GP team. Note: It has been proposed that maybe, someday, Nano will accept some limited GP functions and not others. If that happens, that’s cool. But if it never happens, I’m pretty cool with that too.

So, said another way:

  • PowerShell is the right job sometimes on clients.
  • And DSC is the right job sometimes on SERVERS.
  • But DSC is never right for endpoints (clients).

Technically, you could apply DSC to endpoints and perform at least some of what Group Policy does, especially items like simply registry keys. Or you could build your own DSC resources to do similar work that Group Policy already does. But there is absolutely zero guidance or suggestion from Microsoft that you do this. (Again: See Snover’s twitter comment above: “Group Policy is very well suited to client scenarios which is why you saw a big set of new GPs for Win10.”

Therefore, as it sits today, neither PowerShell nor DSC is a sanctioned replacement for Group Policy on the client… ever.

When Two Management Systems Work (or Don’t Work) Together

Oh, and if you’re considering using Group Policy and DSC, you need to know the (now sort-of famous) quote (also) from Jeffrey Snover when asked:

Q: Will DSC and Group Policy work together?
A: No. They will fight like two raccoons in a bag.

http://www.systemcentercentral.com/day-50-comparing-contrasting-powershell-dsc-versus-group-policy/

And honestly, this is true about any two management systems. Seriously. Let’s replace “Will DSC and Group Policy work together?” with:

  • “Will Group Policy and Intune/MDM work together?”
  • “Will Group Policy and SCCM work together?”
  • “Will PowerShell and Intune/MDM work together?”

In pretty much all cases..  if you’re trying to set the exact same settings on the endpoint… the only answer would be:

A: No. They will fight like two raccoons in a bag… [again: if you’re trying to use two systems to manage the same exact same settings.]

Anytime you’re trying to poke the same value with two management systems with different approaches, you are asking for trouble. So even if you don’t choose Group Policy (which, again, Microsoft is saying is “the best way to granularly configure domain joined Windows PCs and tablets connected to the corporate network” ) … okay. Fine. Whatever you use, use it consistently. For instance, Microsoft Intune has some guidance about using Microsoft Intune and Group Policy together here specifically detail how this situation is handled and provide some guidance to avoid problems like this.

Also: I would say that SCCM and Intune also don’t fight like two raccoons in a bag, if only because they are built from the same team and have a well thought out hybrid model.

Said yet another way, I’m not suggesting you use say, Group Policy exclusively or SCCM exclusively. I am saying you can use multiple management systems for different parts of the world. For instance, Group Policy CAN deploy software to your domain-joined systems, but I don’t recommend it. I recommend SCCM or purpose-built 3rd party tools, which are way, way better than what Group Policy can do with regards to Software Deployment.

You can use SCCM to deploy desktops and use DSC to bring up servers.

So for complete clarity: Group Policy, and say, SCCM can and often do work hand in hand. What I’m saying (again clarifying for emphasis) would be: Don’t use two management tools to poke at the SAME THING with TWO systems. That is just asking for trouble. Use the right tool for the right job.

What about Azure Active Directory ?

  • Creating identity
  • Auto-workplace / MDM joining machines to an MDM service of your choice (Intune, Airwatch, etc.)

So okay. If you have 10,000 iPhones, Android, Windows Phones and some Windows 10 PCs you don’t want to domain join. I can see this as something awesome in a university environment when you tell students: “Buy whatever you want, here are some credentials, and when you ‘join us’ where going to lightly manage your machines so you can be partially, but not mega-naughty on our network.”

That scenario: I totally get with Azure Active Directory and auto-enrolled MDM.

The other nice thing about Azure Active Directory is called out in the blog post:

Azure AD Join is also a great solution for temporary staff, partners, or other part-time employees. These accounts can be kept separate from the on-premises AD domain but still access needed corporate resources.

But, see the earlier talk about what MDM settings can do versus Group Policy settings.

Said another way, and I want to be as perfectly clear as I can here:

Microsoft has no cloud-based way to deliver real Group Policy settings thru Azure Active Directory: it is NOT a current design goal of Azure Active Directory, nor do I ever expect it to be.

If you want real Group Policy thru the Internet, see the three solutions I suggested earlier: VPN or DirectAccess (for domain joined machines) or PolicyPak Cloud (for domain joined or non-domain joined machines.)

That about wraps up my “Why Group Policy is Not Dead” manifesto. I’m appreciative that Microsoft took the time and care to explain to all their customers (and also by extension, their field representatives) about how Group Policy isn’t dead and still very relevant in the Windows 10 eta.

I wanted to take the time to write this to underscore those sentiments and explain how I see Microsoft’s current array of utilities working at their best. As a final thought, again, from the Microsoft blog entry, this says it all:

Group Policy is the best way to granularly configure domain joined Windows PCs and tablets connected to the corporate network using Windows-based tools. Microsoft continues to add Group Policy settings with each new version of Windows.

But that being said, if anyone ever tries to convince you that Microsoft has eschewed Group Policy for something else, here is even more evidence of Group Policy not being dead… Very recent new tools, functions, guidance, and advice from Microsoft which use Group Policy: