MDM & GP Tips Blog

Feb 2023

Go and Get Rid of those Old Group Policies that are no Longer Used

Many people have a hard time parting with stuff. That’s why the self-storage industry is so successful regardless of the what the economy is doing. Just as a lot of the stuff contained in storage units will never be used again, there are probably some unused group policies that are still lingering on your servers taking up space and creating unnecessary clutter. A couple good examples are GPOs that have settings disabled or are no longer linked to anything.

You can disable/enable settings for any GPO in the Details tab in Group Policy Management Console. As shown below, you can disable computer configuration settings, user configuration settings, or all settings configured within the GPO.

Keep in mind that its best practice to only configure settings for one side or the other. A GPO that is configured on both sides should be split into two separate GPOs in the first place. Therefore, there’s no need to have one side disabled as shown below.

Disabling both sides of a GPO means that the GPO is essentially doing nothing. If these settings are no longer required, then they should be decommissioned entirely by deleting the GPO.

If you have a well-designed AD with a well-defined OU structure, you need only link your GPOs to an applicable OU and assign it to the Authenticated Users group. This makes security filtering easy and straight forward. Unlinking a GPO is the same as turning it off for a designated OU. A GPO that isn’t linked anywhere is probably one that is no longer needed such as the GPO shown in the screenshot below. In this case, this GPO could probably be decommissioned entirely.

There are some exceptions, however. For instance, you may use some GPOs for testing purposes that are only used for brief periods. You also may have some GPOs you only want turned on at various times of the year. An example might be a school system that enacts certain policies at the start or close of the school year only.

Remember that you must delete a GPO you must do so from the Group Policy Objects node where you can view all your GPOs in alphabetical order. Right clicking on a GPO link will only delete the link itself, not the GPO. Before you delete any GPO, make sure you have a backup of them just in case you find out down the road that you really do need that policy for something.


Jul 2017

Updated Group Policy Is Not Dead Manifesto - July 2017


I keep getting asked “What do I think of DSC vs. Group Policy” a lot.

So I decided to work closely with Jeffrey Snover, father of Powershell and DSC to come up with some clarifying points.

As such, I have embedded them into my “Why Group Policy Is Not Dead Manifesto”.

If you don’t want to re-read the whole thing , here are the updates for July 2017:

  • Worked with Jeffrey Snover to provide DSC + Windows Client “Truths & Tenets”. (PLEASE use them in Powerpoints, etc. They are blessed as gospel.)
  • Updated Nano server since the infrastructure pieces are now GONE in Nano.
  • Defined “Two Racoons in bag” as “Competing Controllers”
  • Added a link to Security Compliance Toolkit
  • Demonstrated that Security Compliance Manager 4.0 is now dead.

Here’s the link to share with the world:

Jun 2017

Goodbye Security Compliance Manager, Hello Security Compliance Toolkit

Just in time for my next GP class, Microsoft announced the end of road for the “Security Compliance Manager.”

But they also say Hello to the Security Compliance Toolkit. Here’s the quick blog entry from my Microsoft pal Aaron Margosis:

So.. OK Got it. And I’m feverishly updating my GP Master Class to bring this new toolkit to you.

What’s that? Don’t know what the Security Compliance Manager DID .. or how to make the MOST of the Security Compliance Toolkit for Group Policy?

Well, NO PROBLEM .. Just COME to my Group Policy Master Class.. !! July 24-26 (Three days) and get a brainfull in North Carolina with other super-duper Admin smarty pants’s (pantses?)

We still have “front row” seats available.. (I dont really care where you sit in the class.. just SHOW UP!)

Sign up now (Live Training)

Don’t get snaked out of getting your seat.

Sharpen your saw.. and be more EFFECTIVE at running your company’s world.

Sign up now (Live Training)

See you in class. !!

Jeremy Moskowitz (Group Policy Community) (PolicyPak Software)

Jun 2017

Kill more SMB using Group Policy

Item 1 (in case yo missed it.):

Which wacky NAS and SAN and whatever.. items STILL use SMB1 and.. well.. oh well.. sorry. ?
At least there’s this nice list!

Item 2:
Annnnd.. another awesome article on how to use Group Policy to SMB1.. by my pal and Microsoft employee and security expert.. Aaron Margosis !

Jun 2017

When using GP to disable SMB, it's BOWSER, not BROWSER

I got this letter in the ol’ inbox.  I got explicit permission to share it with you from it’s author, with name included. A true warrior is one who makes mistakes, takes ownership of those mistakes, and then shares those mistakes with the world to make it a better place.

Steven Stein, my hat is off to you. Here’s Steve’s letter to me, which I hope helps you out if you plan to kill SMB using GP using my previous post’s links.

-email below-

To my fave GP guy who I try to avoid bothering with useless trivia:   Here is major “How could I be so stupid” accident waiting to happen, and I made it happen re disabling SMB1 using GP.  To myself.  At a client.  Sheesh.

In the instructions, it states to  enter the following Value Data into the “DependendOnService” key – part of disabling (actually NOT enabling) SMB10:  “Bowser”

I knew this was to “enable the Browser” service and though my eyes saw “Bowser” at least a dozen time, my brain read “Browser” a dozen times and my fingers rolled off “Browser” …  all 12 times.  That mental typo rolled out to a test group of four machines.  And, all SMB was disabled on each target.  No browser service, no contacting Sysvol, no mapped drives, no group policy to fix the mental typo.  Not wonderful.

Knowing it would fail, I fixed the GPO and tried to run it.  Anyway.      . . . . Since sysvol was unreachable, the repaired GPO couldn’t be reached.  So, had to manually edit the typo in each registry.  Fortunately, there were only four.

You may want to perform your usual saintly magic and keep a few other folks from getting themselves into a real pickle – like manually editing 10,000 registry entries????

Regards – and keep up the good work.

Steven R. Stein – CCNA, MCSE, VCP

Sr. Systems Engineer

Nov 2016

ADMX Changes thru the years

I love it when I learn new stuff about Group Policy; or when someone shows me stuff I did know in a unique way. This is one of those.

Microsoft has a great blog entry and corresponding spreadsheet to demonstrate “What settings were added or subtracted in ADMX thru the years”?

Absolutely fascinating:

The only time to really “worry” is when Group Policy ADMX settings are DELETED by the product team. Typically: This isn’t done.

But it CAN happen; and if it does, you can set-GPregistryvalue Powershell item to help negotiate those rare cases.

(I go over this in supreme detail in my LIVE training class… hint, hint.)

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.

Mar 2016

Interview with Aaron Margosis.. Part 3 of 3: Microsoft Scams, Whitelisting, and Futures !

Part 3: What happens when someone from “Not Microsoft” calls Aaron

Notes from Part 3 (the final part of the Interview… here !)

Download the audio MP3:

Download the ZIP:

Aarons tips to making people more secure.

Applocker and DeviceGuard Training:

NSA Application Whitelisting using Microsoft Applocker:

Applocker talk from Jeremy Moskowitz at TechEd 2010:

Project Centenial:

Mar 2016

Interview with Aaron Margosis: Part 2 of 3 .. Local GPO, SecGuides, what-to-use-for-what-scenario coaching

My interview with Aaron Margosis.. Part 2 !

Learn about LocalGPOs, Security Guides, why Group Policy is still THE BEST WAY to manage domain joined PCs.

Option 1 (play directly in the browser):

Option 2 (zipped):

Part 2:




Favorite quote from this part of the interview:

“Group policy; it’s been around the longest and is THE BEST WAY to manage domain joined machines” –Aaron Margosis

PolicyPak Cloud Service: Extend real GPOs thru the Internet to domain joined and non-domain joined machines

PolicyPak MDM Settings Manager: