The “Why Group Policy is Not Dead” Manifesto
Updated July 2017.
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:
The actual blog post which is housed on the Windows Intune blog:
Updated for April 2017, now also housed on the Modern Management blog:
Here’s the main quote from the Microsoft-written blogs.. all saying the same thing… 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.
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:
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 four 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.
- Option 4: PolicyPak On-Prem with an MDM Service. As of June 2017, we can take any Group Policy setting, let you EXPORT it, and use your own MDM service (like Intune, Airwatch, or MobileIron) and deploy 100% real Group Policy Settings using your EXISTING MDM service. Again, this “Just Works”. More information, demonstration videos and a free trial, check it out here and some FAQs PolicyPak On-Prem and your MDM service “better together” more about this 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 (Desired State Configuration), a function of PowerShell is best at:
- Bringing up a zillion similar servers, to a set of specific specifications.
- Datacenter and Cloud scenarios
- But not specifically CLIENT scenarios.
Powershell and DSC are ludicrously powerful. But PowerShell is not meant to make ongoing configuration changes on your endpoints. And DSC is 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.
So on May 10th, 2016 .. There was 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.“
But he quickly clarified and honed his statement.. 20 minutes later… 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″
At the time, I needed to interpret / explain Jeffrey a little here. What he was saying was that there are some tools which could be used with Group Policy to configure servers today.. and they stink.. and I agree. Those two tools would be:
- Windows Security Configuration Wizard
- Windows Security Compliance Manager (now dead, as of July 2017.)
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.
July 17, 2017 update.. Even with this blog entry, I keep getting asked the same question: “What’s the deal with DSC on ENDPOINTS?” So I took some quality time, and worked with Jeffrey Snover — PERSONALLY, on this, and together, we co-wrote some “tenets” around DSC working with clients / endpoints. Here is what Jeffrey and I landed on together. And this is the official gospel coming from the mountain:
-
DSC’s design goals & best use cases are for Datacenter & Cloud scenarios (such as “Bringing up 400 servers in a controlled sequence.”)
-
DSC with Windows clients will work: since it’s part of the Windows management platform. But it is not DSC’s design center, and the client management teams are not driving DSC requirements.
-
DSC alongside other management mechanisms (like Group Policy, or SCCM, etc..) would be considered “competing controllers”. Never a good idea with ANY two controllers managing the same resources (aka: target value) for writing.
-
DSC for use as a reporting mechanism about configuration state (as a read-only) mechanism on Servers or Clients could be an interesting idea
Again: This is me *WITH* Jeffrey Snover, agreeing to these words. Thanks to Jeffrey and my other Microsoft pals for for helping contribute to this segment.
Nano Server: What’s the deal with that? (Updated, July 2017).
Continuing onward: Let’s talk about Nano server, why you should and/or shouldn’t care, and how Group Policy and/or DSC relates to Nano server.
First: When Nano server was released it did TWO things. Some “Infrastructure” things, like become a DHCP server or DNS server, and also had the ability to host containers for apps (web apps and the like.)
Now: (July 2017), everything changed with regards to Nano. They have DITCHED the ability to do “infrastructure things.” Don’t believe me? Here’s the blog entry:
and here’s the quote to take to the bank…
“The changes mean that Nano Server, from the most recent update, will no longer be able to implement Server infrastructure roles. It can no longer, for example, run IIS or DNS in your environments like it could at from the earliest Technical Previews right up until the RTM version.”
So: How what does this mean for Nano and GP support?
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: So that’s it for Nano. No GP support; DSC only, and .. that’s AWESOME NEWS for everyone. Since DSC’s design goals & best use cases are for Datacenter & Cloud scenarios (such as “Bringing up 400 servers in a controlled sequence.”) AND since Nano is now devoid of any infrastructure role, there is no tear to be shed that Nano has NO Group Policy support.
So, let’s recap:
- 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).
Again: technically, you could apply DSC to endpoints and perform at least some of what Group Policy does, and expect it to work.. because DSC is built into the Windows platform.
And you could go bananas and 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.” and the DSC “Tenets” above “The client is not DSC’s design center, and the client management teams are not driving DSC requirements.”
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 aka “The Competing Controllers” problem (updated July 2017)
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.]
This is called the Competing Controllers problem, and is “Tenet #3” of DSC + Clients as seen earlier (which was updated in July 2017.)
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 .. when you USE that hybrid model as designed. But you could go bananas and poke the same value with SCCM and Intune, in the WRONG way.
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’s “Competing Controllers”. That is just asking for trouble. Use the right tool for the right job.
What about Azure Active Directory ?
Azure Active Directory is NOT “On-Prem Active Directory in the cloud.”
It just isn’t. It has two main jobs, and here they are:
- 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, then I see some real value here.
I can see this as something awesome in a university environment when you tell students: “Buy whatever you want and here are some credentials. And when you ‘join us’, we’re 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 four solutions I suggested earlier: VPN or DirectAccess (for domain joined machines) or PolicyPak Cloud (for domain joined or non-domain joined machines), or PolicyPak On-Prem with your existing MDM service.
This latest one is new as of June 2017. We announced at PolicyPak we also have TRUE Group Policy support along side any existing MDM service. So if you have Intune, Airwatch or Mobileiron, and want to EXPORT real Group Policy for use with your MDM service, then check out these videos. We built this solution for customers who are just being told “You MUST use MDM and you need a way to get your existing GPOs handled via MDM.” Okay, if you want to do that, we provide the only true viable option for that.
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 era.
Thanks to Jeffrey Snover, Zach Alexander and Aaron Margosis for contributing to this blog entry to help set the record straight.
For me, this blog was a labor of love. 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:
- Tooling and guidance to stop Macro-based attacks.
- Group Policy Analyzer.
- LGPO tool.
- Local Admin Password Solution (LAPS)
- SecGuides for Group Policy-based security deployment.
- Group Policy Settings Spreadsheet which contains all settings including those for Windows 10
- Security Compliance Manager 4.0 (July 2016 !).. (now Dead, yay.. good riddance !!)
- Security Compliance Toolkit 1.0 (July 2017!)
PS: If you’d like a “second opinion”, please see my Pal Stephen’s blog at FoxDeploy. He does a great job contrasting GP, SCCM and DSC. Here’s the link for that second opinion.
Comments (0)