Chapter 1
Enterprise Mobility and MDM Essentials
In this first chapter, we’ll get to know what MDM is, where it came from, and how it’s different than its cousin Group Policy.
I think the best place to start is right at the top of a new page. Like this one.
And that’s kind of what Microsoft did when they decided to dedicate their efforts with EMM and MDM and not continue down the path of investing more features into existing core on-prem Active Directory and Group Policy technologies.
Again, as I stated in the book’s Introduction, Group Policy is not dead. And Microsoft has not “turned off” Group Policy usage for on-prem scenarios, nor should you live in fear that your favorite new, “Windows 10 gismo,” will lose the ability to be controlled by Group Policy.
But, going forward, you can expect that nearly all Windows 10 (and related settings like Edge) should be controllable with either Group Policy or MDM. There are some exceptions, but Microsoft is committed to adding new settings to GPO. That said, don’t expect new major Group Policy features (like enhanced Group Policy reporting new Group Policy Preferences, or additional troubleshooting tools). But do expect more Group Policy settings to be born each and every time Windows 10 ships, and you’ll see these as the Group Policy Admin Template policy settings (ADMX settings) you’ve come to know and love for umpteen years.
For new Group Policy features, like managing the Start Screen and Taskbar and File Associations, while there is some rudimentary stuff in the box, I heartily suggest you take a look at PolicyPak Group Policy edition, which will supplement the missing features most on-prem AD admins are looking for.
The reality is that the concept of Enterprise Mobility and thus using MDM to manage Windows is Microsoft’s new focus, and it’s not looking backward to bolster core Group Policy functions anymore. But at the same time, it is also not killing Group Policy either for use with your existing domain-joined machines.
Microsoft is expecting you to keep using traditional management like Group Policy for some scenarios and modern management with MDM for other scenarios.
Getting Ready to Use This Book
To go through some of the exercises in this book, you will need to own or get evaluations of some software. Or not, and just read the book and see the pictures and get a general feel for what would be involved.
You don’t have to do this now, but to take advantage of the walk-throughs in this book, you will be acquiring the following:
- Azure AD (free) or Azure AD Premium (preferred for this book). And, if you have Office 365, you already have Azure AD.
- An MDM service, like Microsoft Intune, VMware Workspace ONE, or MobileIron. Most of the main services have 30 day (or longer) evaluations.
Again: Don’t do this step now; we’ll tackle that in the next chapter.
If you did want to follow along with all the ideas I’ll be showing, you can take some time now to have some representative on-prem infrastructure to simulate what you might already have now. So if you don’t already have a test lab you can beat up, here’s my recommendation of the following computer names, with the following operating systems:
- DC01 (I recommend Server 2019 or Server 2016.)
WIN10Computer.fabrikam.comjoined to DC01. If you have other machines joined toFabrikam.comtoo, that would be okay and likely useful as well.- WIN10-NDJ-1 not domain joined at all
- WIN10-NDJ-2 also not domain joined at all
You might need more as we go along, but these are a good start.
I suggest you use VMware Workstation or Hyper-V on Windows 10 to make a simulated lab environment. That being said, fair warning, some of the scenarios in Chapter 8, “Rollouts and Refreshed with Configuration Designer and AutoPilot,” won’t work unless you have real hardware. I’ll call those scenarios out when the time comes.
I’m not going to provide any step-by-step instructions for you to bring up your own domain and Domain Controller. But one of my PolicyPak teammates created a video on how to do it here if you’re unfamiliar:
https://www.policypak.com/video/policypak-cloud-how-to-create-a-dc-for-editing-purposes.html
Then join at least Win10Computer to the domain you create; in my examples, I’ll be using the domain name Fabrikam.com.
You might want to have a small gaggle of on-prem AD users pre-created in an OU called Sales. Name your test users anything you like, but you’ll see mine in the book like EastSalesUser1, WestSalesUser7, and so on.
Additionally, as I go along, you might see me manually create other users (in on-prem AD and in Azure AD).
If case you’re curious on the backstory of Microsoft’s fake names, like Fabrikam.com, check out this old blog entry:
https://blogs.msdn.microsoft.com/oldnewthing/20061013-05/?p=29393
Why the Need for MDM
Throughout the years, I kept hearing the supposed death knell of Group Policy. But, it’s more than 19 years since Windows 2000, and, well, it’s still here, and seems pretty darned popular.
So much so that I went a little bananas in 2016 and 2017 and wrote a blog post called “The ‘Why Group Policy is Not Dead’ Manifesto.” I mentioned this in the book’s introduction, but if you didn’t read it then, take a moment to read it now. It can be found by moseying over to MDMandGpanswers.com at:
https://www.GPanswers.com/blogs/view-blog/the-why-group-policy-is-not-dead-manifesto
I highly recommend you take a moment and read it and then come back here to continue. It’s long, so maybe it takes two moments.
So, if Group Policy is so great, then why do we need MDM as something to look to for the future? Because as I said in the introduction, Group Policy cannot be the only transport if we want to solve for new scenarios and use cases.
Because in some ways the future is already here. Here are the key factors I see why people are looking at MDM:
New Workstyle: Constantly on the Go You have one. A cell phone. And it’s “constantly on the go.” In fact those are literally the words that Microsoft uses when it explains its position of the benefits of MDM. And yes, cell phones are the primary device that’s always on the go, but we can all agree that carrying around your laptop is easier than ever.
Note that you can see some of Microsoft’s position with regard to MDM if you read this blog entry called “Managing Windows 10 in your organization - transition to modern management.” It’s found at:
New World: Internet Everywhere If not everywhere, pretty darn close to everywhere. There are always going to be third-world countries and submarines and dead spots. And broken Wi-Fi hot spots. But the prospect of LTE and 4G and (coming soon) 5G everywhere is, well, pretty darned good and getting better all the time.
Now that there’s “Internet everywhere,” it makes more sense to have an always on, always connected system to manage our “constantly on the go” devices.
New Paradigm: No Domain Join We’ve been joining devices to domains since LanManager and NT 3.1 days. Domain joined, however, means that you have all your eggs in the same basket so to speak, which at the time, made a lot of sense. You only really needed to talk to printers and file shares and the occasional SNA device to talk to a bigger mainframe. It made perfect sense.
Today? Not as much.
Endpoints just connect directly to the web-y thing they need and go on with their lives.
The other part of this idea of “no domain join” is a more subtle point, which is the idea that the bad guys could maybe already be inside your on-prem network at any/all times. In days of yore we would assume having a firewall to protect us from the bad guys out on the Internet was enough. But now it’s an actual reasonable assumption that the bad guys are already inside your network, like, right now. And if that’s true, having machines domain joined could actually exacerbate the problem.
If the bad guys break through to the DCs, they could do a big password dump of the hashes of your users and then do a brute force attack. And they could also break into one endpoint, become an admin through an exploit or via a tool like Mimikatz, and then hop from machine to machine in what is known as a “pass the hash” attack.
In my Group Policy book (www.GPanswers.com/book), I show you how to set up Microsoft Local Admin Password Solution (LAPS) to create unique, rotating passwords to mitigate these kinds of attacks.
But having machines that are not domain joined gives you at least these security advantages, perhaps more.
New Reality: New Windows Every Six Months There is only one Windows 10. Except that is totally and completely untrue. The “pitch” we got was that there would be one, final, and total Windows…ever again.
But, as you know by now, there’s a brand-new Windows 10 version every six months. (Microsoft tries to ship new Windows around every March and October.) And each version adds new features. But if you stop to smell the roses for, say, 6 to 12 months, and look backward—holy cow. It becomes a huge evolution of “old Windows 10” to “newest Windows 10.”
Seriously, try it yourself. Go backward and try out Windows 10 1507 compared with say, whatever is latest as you read this book. You’ll feel totally lost and see how dramatically different “old Windows 10” feels to today’s Windows 10.
New Needs: New Versions of Windows To start with, there are the normal desktop and laptop versions we’ve been using for a long time. Like Windows 10 Pro and Windows 10 Enterprise. There’s also Windows 10 Home, but it couldn’t do Group Policy before, and it’s still not designed to integrate with any MDM system.
Beyond that there are a myriad of new sub-versions of Windows. Here are at least five interesting ones:
- Windows on ARM: ARM is a processor type that’s normally found in phones. Before they were reasonably powerful and had reasonable battery life. Now, ARM processors are even more powerful and have even better battery life. As such, Microsoft caught wise to this trend, reengineered the Windows you know and love, and figured out a way to translate x86 instructions on an ARM processor (also known as Snapdragon processors). Result? New laptops without Intel/AMD chips. These laptops run all day and then some. You can learn more about the platform here:
https://docs.microsoft.com/en-us/windows/arm/And an initial test of some ARM laptops here:
https://www.zdnet.com/article/windows-10-on-arm-tests-say-snapdragon-845-could-bring-big-speed-boost - Windows 10 in S Mode: A secure version of Windows 10 that is restricted to only running Windows Store apps. A one-way upgrade path is possible from Windows 10 in S Mode to Windows Pro or Enterprise, which is available as a one-way trip. If you wish to go backward again, you need to format the hard drive. If you want to learn more about Windows 10 in S Mode a talk from Ignite 2017 can be found here:
- Windows HoloLens (and HoloLens2): You’ve seen this thing; it looks like twenty-second century ski goggles. I’ve used this thing two or three times in demo situations, and, who knows. Maybe they’ll take off. Regardless, the HoloLens has MDM built-in.
- Windows 10 IoT (Internet of Things): MDM is built into this version as well, so what you’re doing with the “normal” Windows, you could also do with a PC running Windows the size of a business card. Here’s a homegrown video of a guy installing Windows 10 IoT edition on a Raspberry Pi3:
- Windows (codename) Polaris: This might be a version that comes out without any legacy Windows pieces at all. So no Win32 subsystem at all. It doesn’t exist yet as I write this, but maybe in a year or two or three. Or never. But it’s possible.
New Things That Aren’t Windows (Like Macs and Chromebooks) Look at what the kids are using nowadays at school. It could be a real Windows PC, or it could be a Mac or Chromebook. And all of these things have MDM built into them. Instead of having disparate tools to manage the Windows world and the non-Windows world, there’s an advantage of having one unified tool to deal with all the devices in one place.
New Things That Aren’t Windows (That Don’t Exist Yet) Who knows what the future brings. As such, it does seem reasonable that placing an MDM engine inside it will remain a standard for things that are and aren’t Windows, for devices that exist today and also those that haven’t been dreamed up yet.
Group Policy and MDM Compared
It’s natural to want to compare old versus new. Tried-and-true versus something growing and burgeoning. And in this section I’m going to explain where Group Policy does great, where MDM does great, and also where each of them needs a little work and a little boost of help.
Before I go into details of implementation, the main thing people want to talk about, and quickly learn about most, is where new MDM “stacks up” versus the Group Policy they already know and love.
Let’s start right there: As of this minute (2019), there is no debate. There are more, more, way more Group Policy settings than is possible with MDM.
MDM has about 2000 “curated settings,” that is, settings that are guaranteed to work. Ironically, many of these MDM settings are focused on one legacy piece of software: Internet Explorer. Almost 200 policies alone are for dealing with IE zone settings. Some are what is known as “ADMX backed” (more on this in Chapter 3, “MDM Profiles, Policies, and Groups”) and some are specific and called by the MDM engine.
As of this moment, the official list of settings that Group Policy has in Admin Template settings is 4256, and there are heaps more available configurable items in Group Policy Preferences-land. That said, since Group Policy Preferences isn’t getting any fixes, some major areas, like the Start Menu Group Policy Preferences item, don’t work anymore in Windows 10, and thus their usefulness is reduced. But in short, from a strictly settings perspective, Group Policy is the “winner.”
But, here’s the secret: It’s not a contest.
It seems like it should be a contest, but in reality, it’s not supposed to be a contest at all. In other words, if you were strictly looking at Group Policy “versus” MDM, you might think, “Wow, MDM has a long way to go.” But the MDM philosophy is expressly not to try to take on all of Group Policy’s functionality. Besides, since MDM is only for Windows 10 devices, it wouldn’t make sense to backport, say, Group Policy settings from Windows XP into MDM. So, by design, MDM will always have fewer settings than Group Policy.
MDM is being rebuilt to handle modern scenarios. And, yes, some of those scenarios overlap with existing scenarios we know, love, and need to deal with today (as we did yesterday). But MDM’s philosophy is to analyze each scenario and then come up with a way to tackle it. Again, the goal is not to replicate all of Group Policy’s settings, guts, and complexity (real and perceived).
Another angle and way to think about MDM is that it’s trying to enable control of only what’s needed instead of “throwing the book at managing everything” in the style that Group Policy did. So, fashions change, and the winds might be blowing toward less controlled settings on your PC now than you needed 10 years ago.
So as I write this, it’s true that some admins are looking at what settings are in MDM and throwing their hands up in the air and saying, “Well, I can’t do X with MDM, so I have no way to deal with that.”
There are some answers here: One (shameless plug) answer would be to check out PolicyPak MDM, where one key feature is to enable you to export real Group Policy ADMX, Group Policy Security, and Group Policy Preferences settings and utilize (almost all of) them with your MDM service. That is definitely an option. See https://www.policypak.com/products/policypak-mdm-edition.html for details.
Another option, is to “live without.” This sounds crazy, but stay with me here for a second. Pretend you were to move from a big house with horse stables and downsize to a nice, curated condo. There would be some ups and some downs here. Your big house with the horse stables was awesome, and you had unlimited land and could do whatever you wanted to your house. But when things broke, you had to figure out how to fix it. When you move to your condo, on the one hand, you would necessarily have to downsize (that is, less stuff to bring over), but that might be okay for the trade-off of having less to go wrong. If your condo is nicely curated, new benefits just pop in every so often, like a new clubhouse, new gym equipment, and so on. Heck, maybe this condo doesn’t have horse stables like you’re used to, but it has free built-in bowling! And for a small upcharge, you can take dance classes. And if the plumbing goes bad, someone else fixes it. You just pay your bills every month, and…hey, maybe you could get used to this. So living without the same exact setting or process you used in Group Policy-land might be okay. Maybe you really didn’t need that setting after all, or maybe it makes no sense in a non-domain-joined world. Or maybe there’s a workaround with a PowerShell script (though I personally really don’t love that option compared to a real setting). But again, living without should be analyzed and dealt with as part of your new “condo living reality.”
A third option is to lobby Microsoft with your need and see if they will build it into a future version of Windows. The premier way to do this (as of right now) is via Uservoice: https://microsoftintune.uservoice.com/forums/291681-ideas. You might be able to up-vote a feature or start your own feature and get noticed. Remember, democracy takes time.
And, it should be noted that the “interesting thing you want” requires two pieces:
- Your feature has to be policy enabled in the first place by the Windows 10 product team.
- That policy needs to then be implemented in MDM.
It’s. Gonna. Be. Slow.
Setting coverage in MDM will increase over time. It will. But don’t expect it to “take on” or “take over” all that on-prem Group Policy has been able to do. That’s not part of the deal; at least that’s specifically stated from the MDM team to me as their philosophy.
Now that I’ve talked about the most important aspect, settings, let’s explore the other differences between Group Policy and MDM.
History and Development Time Group Policy has been around since 2000, when Windows 2000 came out. It had some crunchy areas in the engine, which were ironed out around when Vista shipped. Group Policy also scooped up a company called DesktopStandard and rereleased its PolicyMaker program as the Group Policy Preferences, increasing what’s possible in Group Policy to thousands of possible settings with nearly infinite configurations to many of the most commonly configured Desktop areas.
After this major release, not a lot happened in Group Policy-land. Group Policy kind of stagnated from a “getting more features” perspective. And, now, all this time later, Microsoft is still committed to “Group Policy engine” bug fixes as well as delivering the ability to manage new feature settings as Admin Templates, such as managing the Windows 10 Start Menu and Taskbar, Windows Edge, and other new Windows 10 features.
But they are clearly not fixing other well-known bugs in Group Policy, mostly in Group Policy Preferences land. There are many Group Policy Preferences items that simply do not work when delivering settings to Windows 10 machines, and these are not ever going to be fixed. In short, other than Group Policy engine bug fixes, security fixes, and adding new settings via Admin Templates, Group Policy’s upward growth and development status has stopped, but it’s not dead. At Microsoft, it’s in the hands of the “Sustained Engineering Team” within Windows, which means…not dead, but not getting drastically improved.
In contrast, the guts for MDM showed up in Windows 8.0, but even by Microsoft’s own account, didn’t really get fully baked until Windows 10 shipped, which was July 29, 2015. Since then, MDM has increased its coverage of some of the most important settings admins want and the MDM engine has been getting increased development.
Targeting Policies If you’ve used Group Policy, you surely know the idea of LSDOU targeting, Group Filtering, WMI Filtering, and Group Policy Preferences Item Level Targeting. These items provided a huge amount of ways to target your policies to specific users, groups, and conditions on the computer.
MDM, on the other hand, has a way to include or exclude groups, minimum and maximum OS version, Windows health attestation, and some others. We’ll see this in Chapter 3.
Required Infrastructure and Purchases So Group Policy “comes in the box” with on-prem AD. You just stand up on-prem AD and get Group Policy for free. AD is the directory and identity service, and Group Policy is the user and device management engine.
In general, to make the most of MDM, you’ll need some kind of identity directory service. The most common one would be Azure AD, and just to make things complicated, there’s not just one version, there’s at least three versions. You can see the differences between AAD Basic, AAD Premium P1, and AAD Premium P2 here:
https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/active-directory-whatis
A little later, to get started, we’ll sign up for a free 90-day Azure AD Premium account so you can work through the exercises in this book. We’ll get Azure AD Premium when we sign up for our “cloud meal plan” in the next chapter.
MDM: Guts, Protocols, and Moving Parts
MDM is the name we give the moving part of the endpoint to receive settings and perform work. But underneath it all, on the endpoint, there are protocols and moving parts that do the actual work.
Let’s break it down to understand the parts of MDM.
OMA-DM: The Protocol
Group Policy uses Kerberos and SMB to coordinate its efforts of authenticating a user or computer, then downloading directives.
MDM uses a much lighter weight system based upon XML.
The protocol is called OMA-DM (sometimes spelled out as OMA DM). This is an open standard protocol. The OMA part stands for Open Mobile Alliance. And the DM part stands for Device Management.
OMA-DM deals with the joining aspect of a machine to an MDM system, which is properly known as enrollment. And OMA-DM deals with sending messages down in real time, say, to deliver a new policy via push, gather its status, or perform a remote wipe.
Honestly, it’s too freakin’ boring to go into details for OMA-DM. You really don’t want to read about computer-to-computer XML-specific commands to enroll a device, get the acknowledgment, and so on.
The good news is that this is dealt with for you by Microsoft, who supports the OMA-DM protocol inside the Windows 10 MDM engine, and by each MDM vendor. They just “talk the same language” and magic occurs.
And this is also why you can pick any MDM vendor. As long as they’ve written their specs to the OMA-DM standards, Windows 10 will pick it up and run with it. Again, you don’t want to read these boring details. But if you did, here would be the two places to get that gnarly XML information. The OMA specs themselves can be found at www.openmobilealliance.org/wp/.
Microsoft’s supported specs for Windows 10 can be found at:
https://docs.microsoft.com/en-us/windows/client-management/mdm/oma-dm-protocol-support
CSPs: Configuration Service Providers
To me, the interesting part of MDM is the CSPs, or Configuration Service Providers. These are the build-in mini-receivers within Windows 10’s implementation of MDM. They accept OMA-DM directives as XML, process them, and…bingo, something happens on the client.
In Group Policy-land, we used CSEs, or Client-Side Extensions. If you’ll remember, there are 39 “in the box” CSEs for Group Policy. Things you know and love, like Admin Templates, Folder Redirection, Group Policy Preferences Printers, and so on. Group Policy CSEs are only available on real Windows versions, and even then, not every Client-Side Extension is available on all real Windows versions. For instance, the Group Policy Preferences CSEs (21 of them) are not available on Windows Home.
Now in MDM-land, we use CSPs. And here’s the thing: CSPs are in real Windows (like Pro and Enterprise) and also in these new alternative Windows types, like Windows Mobile and Windows IoT, and…whatever comes next.
And they’re in non-Windows devices too. Like iOS, Android, Macs, Chromebooks, and more.
This means you’ll need to stay up-to-date with any new CSPs that come out from Microsoft, but really, only for the Desktop versions you need to worry about. Remember that with every Windows 10 release, there might be either new settings to existing CSPs or even new CSPs.
An example of three CSPs and a matrix of which version of Windows 10 they would apply to can be seen in Table 1.1.
Table 1.1 Example CSPs and which versions of Windows they apply to
| Home | Pro | Business | Enterprise | Education | Mobile | Mobile Enterprise | |
| AppLocker CSP | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| Firewall CSP | ✗ | ✓ | ✓ | ✓ | ✓ | ✗ | ✗ |
| Policy CSP | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
These are all detailed inside Microsoft’s Configuration Service Provider Service reference, found at:
There is one CSP you should get to know, like, really well, before you head charging down the road of using an MDM service.
It is called the PolicyCSP and it has two abilities. On the one hand, it can drive settings indirectly. On the other hand, it can do what’s called ADMX-backed policies. As you might imagine, ADMX-backed policies tie back to real Group Policy settings.
I’m not really ready to talk about the PolicyCSP in detail yet—until you’ve selected an MDM service, and you can see how to interact with it. So, stay tuned; this topic will come back soon enough in Chapter 3.
For more about CSP details for IT Pros, read:
WMI-to-CSP Bridge
Windows 10 has a small trick up its sleeve for when a machine has no MDM service to talk with. It’s called the WMI-to-CSP Bridge.
This is a way to deliver some CSP commands via scripts, C#, and/or WMI. You can deliver these commands using…well, whatever you like. You could write a login script or deliver the commands via SCCM or have some custom program that did the job.
The point is that if you look at the CSP list, there are a lot of MDM settings you can poke and manage…without subscribing to any MDM service at all.
Okay, sure, you then have to do everything yourself, with a script or some way to program it. Anyway, it’s in the box if you want it. The two resources to check out here would be as follows:
MDM Bridge WMI Provider docs found at:
https://docs.microsoft.com/en-us/windows/desktop/DMWmiBridgeProv/mdm-bridge-wmi-provider-portal
Using PowerShell scripting with the WMI Bridge Provider found at:
MDM Service
Picking an MDM system as a service is discussed in the next chapter; but there’s a big insider secret. This secret is so big, so protected, and I kind of cannot believe it’s been kept as long as it has.
Ready for the secret?
Here it is: no single MDM system can fundamentally manage Windows better than any other MDM system.
Did I just blow your mind?
“Why is this?” I hear you cry! Because ultimately all MDM services are limited to using the CSPs that Microsoft provides for Windows 10 in the MDM platform, and, as of this writing, writing custom CSPs isn’t permitted.
So all the MDM providers must be pushing the same buttons, remotely using the OMA-DM protocol and twiddling the bits of the CSPs to do the same work. And that’s it.
There is an interesting caveat here though, which is that different MDM vendors could expose and “pretty up” the available CSP settings in their UI. We’ll see more about this in Chapter 3. But the quick story is that some vendors do a better job than others about lighting up the available CSP settings in a pretty clickable MDM UI.
I’ve heard this referred to as “First Class” settings. So if your MDM provider doesn’t make a particular setting available as a “First Class” clickable setting, you can always poke and set the setting manually. I’ve heard this called “Third Class” settings. Again, this is something we’ll see in Chapter 3.
It is possible to squint a little bit and extend your MDM service to do more than it was originally intended to do. In fact, there are some add-on products to MDM services. See the next section to see how that’s done.
But fundamentally, “any MDM will do.”
Because they’re all pushing the same buttons and pulling the same switches because they’re all eventually poking the settings of the in-box CSPs of Windows 10.
Extending Your MDM Services with Third-Party Tools
Even though all MDM services are limited to using the same CSPs, it’s possible for an MDM service (or anyone really) to extend Windows management in some other way and use MDM as the transport for doing so.
For instance, MobileIron has a paid add-on product called MobileIron Bridge that is a fancy way of deploying PowerShell scripts. It simply uses the MDM’s built-in CSP for deploying MSI files and, then, drops a PowerShell script on the machine and has a little “runner program” to execute the PowerShell scripts.
And Intune itself is also made up of its own “built-in” third-party tool of sorts. It’s called the Intune Management Extension. And right now, it bolts on two pieces of functionality that customers kept asking for: running PowerShell scripts and installing Win32 apps (.EXE and .MSI apps with multiple files). It does this by installing a service into Windows, after Windows 10 enrolls into Intune. Maybe the Intune Management Extension will grow in the future to do more things, but as of this writing, that’s what it does right now. You can learn more about running PowerShell scripts at:
https://docs.microsoft.com/en-us/intune/intune-management-extension
You can learn more about Win32 app management at:
https://docs.microsoft.com/en-us/intune/apps-win32-app-management
Another instance of how MDM can be extended is how we do it with PolicyPak MDM. For 200 percent clarity, PolicyPak MDM is not its own MDM service like Microsoft Intune or Workspace ONE. Instead, PolicyPak MDM’s goal is to add onto your existing MDM service (whichever you’ve picked) and “do more” with it.
So, for example, we let you take your on-prem Group Policy directives (and other magic PolicyPak settings for Windows 10 management) and get them onto your Windows 10 machines. How do we do this? We wrap the directives up into an MSI and then leverage the MDM’s CSP for deploying MSI files to get your desired configurations onto the machine. This delivery magic via MSI enables you to deliver the full range of both Group Policy settings and PolicyPak’s extra settings (managing browsers, removing admin rights, taming Java, etc.)—all things that neither MDM nor Windows in the box could naturally do.
Additionally, installing the SCCM agent through an MDM service extends your MDM service as well. Wherein you then get to do all the SCCM things you did before as you’re used to, like getting detailed inventory of MDM machines rolled up into your SCCM console.
The point is that any given MDM service itself is restricted in what’s possible with what Microsoft provides within the CSP list. But as I’ve shown in this section, the workaround for MDM’s shortfalls is to add on a booster rocket….delivered as a bolt-on and delivered via the MSI CSP method when needed, like what I’ve shown here in these examples.
Final Thoughts
In this chapter I explored the essentials of MDM.
You should now have a grip on why MDM is interesting for scenarios that cannot be covered with on-prem solutions like Group Policy and SCCM. Additionally, I hope you got the memo that I’m not beating up either Group Policy or MDM in any way: Group Policy is great for what it does, and MDM is great for what it does. And, as I said, it’s not a “contest” to see when MDM will take on all of Group Policy’s settings, because that’s not in the game plan.
I also hope going through MDM’s guts and moving parts helps you understand how it’s all put together. And the good news is, it’s not complicated, which is a nice plus.
Additionally, since MDM is always being updated and taking on new settings, you should check in from time to time to see what’s new, especially when Windows is updated. The best URL for that is:
Hit me up on twitter at @jeremymoskowitz and tell me the one thing you learned in this chapter, Chapter 1. Use the hashtag #mdmbook.
Like … “@jeremymoskowitz, in Chapter 1 of your #mdmbook I learned….” Then just tell me one neat thing.
I can’t wait to get your tweets.
And I’ll remind you at the end of each chapter, too.
Last, flip back to the beginning of this chapter to see my suggested on-prem test lab details. If you haven’t got those set up yet, now would be a good time. In the next chapter, we’re going to test-drive Azure AD and select an MDM service. So, best to get the on-prem test lab set up and ready to go before we dive into new waters.
See you there.