MDM & GP Tips Blog

Oct 2016

Next Group Policy Training: Atlanta. (And some security stuff that scared my pants off !)

Next GP Class Stop: Atlanta. (And some security stuff that scared my pants off !)

Hey Team.. ! Just got back from Atlanta… where last week I was at Ignite.

Quick Ignite report: Nothing blew my face off, but it was nice to physically be back in touch with friends, customers and students.
The human connection CANNOT be underrated !

Check this picture out of a dinner on Wednesday night. Can you name all the people in this photo: ?

And, guess what? I’m coming back to Atlanta… TWICE MORE this year.
First: Techstravaganza 2016 Nov 18th !

What is it? This is the annual Atlanta IT Pro user group meetup, and it’s awesome. And I’m giving two speeches and one is the keynote ! Come hear me speak about:
– “Top Windows Server 2016 and Windows 10 Gotchas”
– “Why Group Policy isn’t dead, still matters, and what’s new in Group Policy for Windows 10”

When is it? Nov 18th, 2016.. One Day only !

How do you sign up? Sign up and get tickets here:
Second: My next Group Policy Class : Dec 12 – 15 (Four Days)

We have two seats remaining my class next week in Chicago.. and see you all who are coming NEXT MONDAY!!
And it’s really been like forever since I’ve had GP class in Atlanta.
So.. Guess where I’m going next!? Atlanta ! Dec 12 -15.
We’ve got a great location, great room rate, it’s just going to be a super awesome amazeballs class.. I know it.
And you can join aboard… How do you do that I hear you cry?
Price: $2500 for the four days.
Results?: Priceless.
So what scared the heck out of me? Well, check this out.. There’s a video you have to see. It will freak you out.. !
Stealing login credentials from a locked PC or Mac just got easier

Some possible remediations could be:
– Block the USB\Class_02 device using a Device Installation restrictions GPO as a countermeasure based on the following info:

Another proposed protection was:

These are both UN-tested, and were suggested by a two fellow MVPs (not me.)

You’ll learn about Device Installation Restrictions in my Group Policy class. And a billion other security tips and tricks.

So.. what are you waiting for?
Dec 12 – 15 in Atlanta… !

Get Training

See you there !!

Aug 2016

Windows 10 Build 1607 (Anniversary Edition) - Group Policy

So.. “Windows 13” is out.. I mean… “Windows 10, Build 1607 Anniversary Edition” of course. And, it’s a pretty big update. To make your life easier I rounded up all the news about Group Policy and this build into one place. THIS PLACE.

Here we go !

Item #1: Get the latest ADMX download

Item #2: What to do with this ADMX download (video I made back in the day)

Item #3: Some Policy Setting items are ONLY in the Enterprise/Edu editions and NOT in Pro.

Here’s that list so you don’t punch a wall, wondering why a setting isn’t working as expected on your Pro machines.

Item #4: Latest ADMX Spreadsheet

First: The latest Group Policy Spreadsheet is found at:
But there are some old ones too. The right one to get is:
Here’s a picture so you don’t mess it up (like I did):

Item #5: How do you find ONLY new policies for Win 10 Build 1607?

When you open the spreadsheet it, look at COL H which says “New for”…
Here’s a picture:

Item #6: Microsoft Edge got some new policies
And .. at least one only works when the machines are DOMAIN JOINED ONLY (so Local Policy won’t work too if the machine is not domain joined.)

Item #7: How to delay the Anniversary Update.

Item #8: A bunch of stuff has changed around Windows Update.

I’m working on chewing thru this; and promise to have it sorted out by the time the Chicago class happens.
Soooooo… COME to the Chicago class, will ya!?

With over half the seats sold, don’t be “that guy” who missed the boat. Remember: Windows 10 is now already up to “Windows 12” or “Windows 13” depending on how you count the updates. If you don’t keep up with what’s new, you’re gonna fall so far behind you might as well throw out everything and go back to abacii (abacuses?). Whatever, you get the idea. Details:

Where: Chicago (Addison)
When: Oct 10-13. (Four Days)
Cost: $2400.
Guarantee: 100% guaranteed to be awesome or your money back. Really and truely.
How to sign up (up to 3 people):
Got 4 or more people? Gotta call us for mega discount: 215-391-0096.

Thousands of admins have taken (and RE-TAKEN) my killer Group Policy Class.

Get up to speed (or get up to speed AGAIN if you need to).

Jun 2016

Never a dull moment with Group Policy (or what to do about MS16-072)

So on Patch Tuesday, Microsoft released a patch to prevent a theoretical “man in the middle attack” when  GPOs are downloaded from your servers to your endpoints.

Okay.. Fine. Sounds good. In fact, here’s the tech note on the problem. Fix for GP elevation

But when that patch is applied, there is a “double increase” in security, one with an unintended consequence.

That consequence is that SOME GPOs will no longer apply when you expected them to. You could call this a “breaking change”, but.. stick with me, I think Microsoft wanted this behavior updated. And it’s not TERRIBLE; it’s simply somewhat inconvenient to fix and make right again.

How to expose the new behavior

Warning: I have not done the full end to end testing on this. This is simply my understanding of the issue and what’s going on here. With that disclaimer, the problem will occur for you when:

1. The patch MS16-072 is applied to your endpoint computers (the ones which PROCESSS GPOs).

2. Admin has REMOVED Authenticated Users in Security Filter.

Here’s a GPO in “normal” state:

3. Admin has specified specific USERS (directly or via Group membership) in Security filter.

Here’s the same GPO in “revised” state, specifying a security group which contains only users:

 Ergo: The COMPUTER ACCOUNT itself has no READ access to the GPO (nor should it need it.)


The ORIGINAL behavior is:

ALL user-side GPOs should be processed when a USER has READ/AGP rights, even if the computer itself has no read / AGP rights access to a particular GPO.


The UPDATED (unexpected) result is:

User-side GPOs are not processed (if the computer cannot perform the READ operation.)


And why is this occurring? Well, here’s the answer from the KB: “Before MS16-072 is installed, user group policies were retrieved by using the user’s security context. After MS16-072 is installed, user group policies are retrieved by using the machines security context ”

So the big change is that in order to process USER side GPOs, the COMPUTER needs READ access. And when you remove AUTHENTICATED USERS from the GPO, the COMPUTER cannot perform the READ it needs.. and hence, user-side GPOs are not processed as expected.

What to do next: 

  • If you wanted to MANUALLY update any existing GPO to then recover from this breaking change, there are two possible manual ways:
    • Manual way #1: Simply add Domain Computers to the Security Filter as seen here:
    • Manual way #2: Add Domain Computers “indirectly”, by using the Delegation | Advanced and specifying READ but NOT “Apply Group Policy” as seen here
  • If you wanted to AUTOMATICALLY buzz thru ALL your GPOs and find the ones with problems. Here’s a quick powershell script:
  •  If you wanted to AUTOMATICALLY fix all your GPOs, there are two ways to do it:
    • One-liner Powershell script as follows (thanks to  Rudi Vanden Dries in the comments of this blog for the tip):
      Get-GPO -All | Set-GPPermissions -TargetType Group -TargetName "Domain computers" -PermissionLevel GpoRead

Why ?

You might be asking WHY Microsoft made the change.

Update 6-22-16: Well, the Official Microsoft Response to the patch is here: 

Short story: It’s a prevent of a theoretical attack, and ensures that the computer does all the work with Kerberos.

Update 6-17-16 to the question “Is it better to just add ‘Read Rights’ to Domain Computers directly to the delegation tab?”

So after this post went live, I got the question (in several ways) which boiled down to

Jeremy, should I add DOMAIN COMPUTERS to the SECURITY FILTERING section? Or should I just add DOMAIN COMPUTERS to the DELEGATION TAB?

So there are advantages and disadvantages to each approach.

Method 1: Adding DOMAIN COMPUTERS to Security Filtering section advantage and disadvantage

When you add Domain Computers directly to the Security Filtering tab, you can actually *SEE* that you did that. Again, here’s the screenshot from earlier if you take my advice:

In a PERFECT world, if you followed best practices by NOT mixing USER and COMPUTER side stuff, there would be no particular consequence for adding DOMAIN COMPUTERS to the Security Filtering tab. Said another way, if NO GPOs had COMPUTER side stuff, then the computer would have nothing in particular to apply when you made this change.

Method 2: Adding Domain Computers “indirectly”, by using the Delegation tab advantage and disadvantage

Method two is that you use the Delegation tab and specify READ but NOT “Apply Group Policy” as seen here the end result in the security filtering tab is this (when you press OK) is simply this:

When you do this, you don’t get CLARITY that the rights are correct. You have no idea that the Group Policy will actually process.. unless you peek (again) at the Delegation tab.

But the upside here is that if you have “mixed GPOs” with COMPUTER side stuff into the same GPO, you won’t start to process “dormant items” that didn’t apply yesterday and will (uh-oh) magically apply today.

So I guess, ultimately, this is my vote.. the indirect way… with the downside that I have to verify the GPO is “ready to rock” by clicking the Delegation tab and verifying that Domain Computers is in there. (boo.)

Note also that Method 2 should be used for those still on SBS 2008 or SBS 2011; as SBS has a special process which cleans out some GPOs back to their original baseline (if you do Method 1.)

Update 6-22-16 to the question: “Should I add Authenticated Users or Domain Computers” when I choose a method?

So I got this question a lot, and here’s my vote: Use Domain Computers and not Authenticated Users. Yes, either will work, but I think Domain Computers is slightly better to add.

Authenticated Users is simply more rights than necessary. (But just a little bit.)

Domain Computers are.. well, domain computers. And Authenticated Users are… well, Authenticated Users *AND* Domain Computers.
(As I like to say… “Computers are People Too”).

So, it’s the minimum rights required are Domain Computers.. because THEY (the computers) are now in charge of the whole “Lookup and download” operation, Where before.. it was a two-part affair.

Making the change permanent in Active Directory for future / newly born GPOs

So, okay. If we’re going to go with “Method 2” .. maybe you want to make this change permanent for all future / newly born GPOs. Which, I think is a good idea. Here are the exact step-by-steps you need to do this. (Tip: If you don’t trust my advice, pre-check this out: The steps which I verified:

  1. Open ADSI Edit
  2. Connect to the schema
  3. Find the the object “CN = Group-Policy-Container” 
  4. Find defaultSecurityDescriptor and add this at the end:  (A;CI;LCRPLORC;;;DC)

TIP: The “DC” in the string is “Domain Computers” not the “Domain Controllers”.  In case you care, Domain Controllers “short name” is “ED” which means “Enterprise Domain Controllers”.

5. Close ADSI edit. Then also close the GPMC (if opened.) And re-open the GPMC.

Check to see if it worked. If it did, all new GPOs you create will have the following stamp on them:   

6. If it did not work, then, ensure that all DCs get the update (aka synchronize all DCS) then … reboot all your DCs. You can reboot them one by one. -or- Another option is to update the Schema Cache:

Again: when this is over, all new GPOs you create will have the following stamp on them:  .

What about Microsoft AGPM (and tools like it, like NetIQ GPA , etc.? )

So another Microsoft article, posted from a Microsoft PFE is found here: which re-iterates some of my points and step-by-steps. That being said, I didn’t talk about AGPM here, and he does a pretty good job explaining what to do in AGPM land. In short, the steps are:

  1. Do all the steps to the LIVE GPOs like we already talked about.
  2. Mass Import from Production AFTER that.. or else AGPM doesn’t know you did anything in the real world.
  3. Set AGPM’s permissions such that when a GPO is DEPLOYED it has the right stamp.

Again, the blog entry does a reasonable job of explaining that, so I’m not going to re-do the step-by-steps here.

Brief commercial message:

  • Hope this information helps you out, and you’ll consider getting serious GP training from me at … Live and Online training !
  • And consider PolicyPak to manage the heck out of all browsers and apps: IE, Firefox, Chrome.. plus Java, Flash, and hundreds more. Thru Group Policy, SCCM or thru the cloud.

Your pal, Jeremy Moskowitz, Enterprise Mobility MVP.

Thanks to my Fellow Enterprise Mobility MVPs for technical review of this article.

May 2016

AMA replay now live, and Group Policy Not Dead Manifesto .. Updated !

Actually, this has three things:

1. AMA session replay.

I did a super fantastic ASK ME ANYTHING (AMA) session with my hosts at AdminArsenal. It was super fun. The replay is here: 

2. Group Policy not in Nano Server (Not News to me), but I updated the Why GP is Not Dead Manifesto.

Also, I already knew this, but apparently it was NOT known by some that Windows’ new Nano server has no Group Policy support.

You’d think I’d be upset about this, but I’m not. Not even a little bit. As such, I’ve updated my “Why GP Is not Dead” manifesto.

It’s another Blog entry, and that link is here. You can find that important reading here.

Search for the phrase: May 10th, 2016 update

3.  Microsoft also figured out that it’s too insane to bring up a new Windows 7 machine nowadays with 897 patches. So they they have a “rollup” of all the important fixes since Windows 7 SP1. Excellent. This is awesome.

Download it here to add to your (new) Windows 7 + SP1 build images.

Here’s the link. and

Be sure to check out the associated KB article,

Thanks and talk soon !

May 2016

How to Block Windows Store in Windows 10 Pro with Group Policy (even though the GP setting

You might have read the news that it’s no longer possible to use the built-in Group Policy SETTING to prevent access to the Windows Store starting in Windows 10 / 1511 with some updates. I don’t make the news, I just report it.

The official article at Microsoft is “Can’t disable Windows Store in Windows 10 Pro through Group Policy:“. Except, good news.. turns out there IS a way to prevent Windows Store from running with Windows 10 Pro Video.


For more killer tips, be sure to sign up at for the  newsletter list to stay informed.

For Group Policy training, (live and online) sign up at

And to extend Group Policy to manage applications and browsers, check out

UPDATE: Found another technique which works with “Software Restriction Policies”, which is a little less intense than using, say, AppLocker to do it. Personally, I prefer the method in MY video, but this alternate method using SRP should work a-ok for most people as well. Link to another blog / video.

Apr 2016

Windows 7 and slow Windows updates


This one has been annoying me for a while; so I found two resources which explain how to stop Windows 7 from taking (literally) forever, or at least hours to update.

Resource 1 at Infoworld.

Resource 2 at Stack Exchange. Look for the words “This issue has come and gone over the years with different fixes along the way…” and follow his instructions. Worked perfectly for me. Requires downloading two patches, then going offline, installing them, then going back online to complete. Again: Personally worked for me and I can vouch this worked as expected (in my cases anyway.)

Hope this helps you !

Apr 2016

Fix GPPrefs Scheduled Tasks and also Updating AD

A student in a recent class showed me this article, which demonstrates how to make Scheduled Tasks (correctly) run as SYSTEM. I didn’t know this was a bug, but I’m glad I know there’s a fix !

The same guy also has a nifty script to perform a full replication of all DCs in the domain. Handy if you’re getting inconsistent results with GP. Here’s a pointer to that nice script:

Good job, MadDog 2050.. whomever you are !

Mar 2016

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:

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:

  1. DSC’s design goals & best use cases are for Datacenter & Cloud scenarios (such as “Bringing up 400 servers in a controlled sequence.”)
  2. 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.
  3. 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.
  4. DSC for use as a reporting mechanism about configuration state (as a read-only) mechanism on Servers or Clients could be an interesting idea
 – Jeffrey Snover co-written with Jeremy Moskowitz, with Microsoft’s Aaron Margosis and Zach Alexander with the assist.

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.

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:

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.