MDM & GP Tips Blog

So we said that CSPs are embedded interfaces in the Windows 10 OS that give MDMs the ability to read, set, modify and delete configuration settings.  This gives administrators the ability to command and deliver settings for enterprise devices.

There are many CSPs, but there is one particular one that is special.  That one is the Policy CSP. 

Like all CSPs, the MDM engine takes directives from it.  What makes it prominent is that it contains so many of the common items that admins are used to managing in Group Policy.  For instance, the Policy CSP contains settings for common components such as:

• Browser
• Defender
• Device Guard
• Power
• Remote Desktop Services
• Update

For instance, may you want to prevent users from terminating a task in the Task Manager.  Well, the Policy CSP contains a TaskManager Policy and the name of the settings is TaskManager/AllowEndTask.  The data type for this setting is integer and the supported values are as follows:

• 0 - Disabled. EndTask functionality is blocked in TaskManager.
• 1 - Enabled (default). Users can perform EndTask in TaskManager.

The TaskManager Policy is supported in the following Windows 10 Editions.

Chart taken from https://docs.microsoft.com/en-us/windows/client-management/mdm/policy-csp-taskmanager

The Policy configuration service provider contains sub-categories.

• Policy/Config/AreaName – Handles the policy configuration request from the server.
• Policy/Result/AreaName – Provides a read-only path to policies enforced on the device.

The Policy CSP have a scope to which its settings can be configured.  Some policies have settings that only apply to the device itself regardless of who is logged on to it.  Others apply to the user which means that settings can vary depending on which user logs on.  Each policy includes a path that defines its scope.  The possible scope paths are as follows:

User scope:

• ./User/Vendor/MSFT/Policy/Config/AreaName/PolicyName to configure the policy.
• ./User/Vendor/MSFT/Policy/Result/AreaName/PolicyName to get the result.

Device scope:

• ./Device/Vendor/MSFT/Policy/Config/AreaName/PolicyName to configure the policy.
• ./Device/Vendor/MSFT/Policy/Result/AreaName/PolicyName to get the result.

This is a quick introduction to the PolicyCSP. In other blog articles we'll examine more how to take advantage of it.

CSP stands for Configuration Service Provider.  You might think Intune i somehow a CSP but that would be incorrect. 

Intune is an MDM service. 

A CSP is a component of the Windows 10 operating system; kind of like a Client Side Extension (CSE) is to Group Policy.

The CSP is what gives IT personnel the ability to apply device-specific settings to Windows devices.  In our case, that means using Intune to do it.  In doing so, IT can be assured that all company devices are compliant with the standards and policies set forth by the organization.  Keep in mind that you can deliver setting configurations to CSPs through other means than an MDM such as Windows Configuration Designer, which is used to create provisioning packages.  

So what are these CSP’s?  Well, you can go to Microsoft’s website and look them up at https://docs.microsoft.com/en-us/windows/client-management/mdm/configuration-service-provider-reference.

Notice that not all operating system editions support each CSP because some settings are unique to select OS versions.  In addition, many CSP’s contain settings introduced in designated Windows versions.  This means that the settings are not supported in versions prior to that release.  

So let’s look at the inner workings of a CSP.  Let’s say you want to enable BitLocker for all the mobile devices used by your HR and Finance personnel.  Well, there is a CSP for that called BitLocker CSP.  If we look at the available settings for that CSP, they look like this:

Chart came from https://docs.microsoft.com/en-us/windows/client-management/mdm/bitlocker-csp

CSP settings accept some sort of data type value to enable or disable the setting.  In this case, the data types are integers, either a 0 or a 1.  A value of 0 disables the settings while a value of 1 enables it.  The setting RequireDeviceEncryption for instance allows an administrator to require the use of BitLocker encryption on designated devices.

So let’s say our security minded administrator wants to deliver an integer data value of “1” to the BitLocker CSP contained within the HR and Finance devices.  That administrator just needs an interface to configure, assign and deliver them, and that is where Intune comes in.  Below, a Profile was created called “BitLocker Settings”  that now delivers the selected Windows Encryption settings.

How easy was that?  Ridiculously simple indeed. 

Keep in mind that not all CSP settings are "surfaced" as settings within Intune. 

So what happens when we want to configure settings on a CSP that doesn’t appear in Intune?  Well, there are two options.  The first would be to sit and wait around with our fingers crossed and hope that Microsoft Intune developers will add our desired settings soon.  The other way is to take matters into our own hands and make a Custom OMA-URL.  So how do we do this?

A key (and useful) example is how to make MDM vs. GP more deterministic.  Starting with 1803 however, a policy called “ControlPolicyConflict/MDMWinsOverGP” was created to give you control over which one won.  So while the policy setting doesn’t appear by default, we can create a customized URI for it that will enforce the outcome we want. 

Intune provides an interface to create Custom OMA-URI policies within a profile.  We just have to provide some information which is outlined below. 

• Name
• Description
• OMA-URI
• Data Type
• Value

In the case of this CSP, the possible values are

• 0 (default)
• 1 - The MDM policy is used and the GP policy is blocked

In the case the creation process will look like this:

For more information concerning this particular CSP:

https://docs.microsoft.com/en-us/windows/client-management/mdm/policy-csp-controlpolicyconflict#controlpolicyconflict-mdmwinsovergp

But the point is: Don't have a "knob" for the setting? Make a custom OMA-URA and you're off to the races.

If you are familiar with the concept of Windows Server Active Directory, then you already have a good idea of what Azure AD is.  It essentially is a cloud version of Active Directory which was introduced in Server 2000, which seems like forever ago.  In technical terms, it is Microsoft’s cloud-based identity and access management service.  The basic concept of the two AD’s is the same; users logon and authenticated to AD and then access resources.

So why the need for Azure AD?  Well, we live in a different world today than we did when Server 2000 was unveiled.  We live in a mobile age that is dominated by the Internet and traditional AD wasn’t designed for a world like that.  Azure AD on the other hand is designed to support web-based services that use Representational State Transfer API interfaces.  In simple terms, it was created for cloud based applications such as Office 365, Salesforce.com, etc.  To do that, it had to be based on completely different protocols, specifically SAML and OAuth 2.0. 

There are a number of versions of Azure AD:

• Azure Active Directory Free
• Azure Active Directory Basic
• Azure Active Directory Premium P1
• Azure Active Directory Premium P2

The differences between these different versions is two fold.  As you move up from the free version, you get more features, which of course, you guessed it, costs more money.  Except for Azure Active Directory Free, which is complimentary if you have a paid subscription to Office 365, Microsoft Dynamics CRM Online, Enterprise Mobility Suite, or other Microsoft services, the other versions require some sort of subscription free that goes up along with the number of feature packages.

There are several integral components of Azure AD.  They are:

• Azure AD Directory – the equivalent to the domain of Windows Server AD, it is what contains the tenant’s users, groups, apps, devices, etc.
• Azure AD Account – an identity created through Azure AD or another Microsoft cloud service such as Office 365.

The Azure AD account gives users access to their organization’s cloud service subscriptions.  On a Windows 10 device, it is referred to as a Work or School Account.  The screenshot below illustrates how one would manually join a Windows 10 device to Azure AD.

Azure AD is highly scalable.  Even the free version can contain 500,000 objects.  With so many users, accounts and applications, an organization undoubtedly needs one or more administrators to manage everything.  Below is the management screen of Azure AD. 

So how does Azure AD relate to Intune? 

Well, the two work hand-in-hand. 

In practivcal terms, you really cannot have Intune with Azure AD. 

In the same way that Windows Group Policy helped deliver and manage settings for Windows domain join machines, Intune is the mobile device management tool that integrates with Azure AD in order to manage settings as well.  It also protects your organization’s resources by controlling how users can access and share it and can lock down devices that may have been stolen or compromised. 

Another article.. Not mine.. from Microsoft. Good one.

https://blogs.technet.microsoft.com/askpfeplat/2018/09/03/is-group-policy-slowing-me-down/

I do talk about this in super detail in my GPbook.. in the Troubleshooting chapter with more details; but this is an excellent first start.

I also talk about this topic in my talk from TechEd here:

https://channel9.msdn.com/Events/TechEd/NorthAmerica/2014/WIN-B328

And give you some tips and tricks for analyzing the data and making conclusions.

Hope this helps you out !

There are a number of things that are complicated and hard to comprehend at first.  College algebra, quantum physics and Microsoft pricing when it comes to their cloud services.  For instance, here is a screenshot of just some of the available licensing for a school system that currently utilizes Microsoft cloud services.

At first glance, trying to wrap your head around all of the available licensing options can be as exhaustive as contemplating the size of the universe.  There are so many ways to slice and dice subscription licensing when it comes to Office 365, Intune, Azure, etc.  For the sake of this blog series, we are going to make it simple. 

You want the ability to do mobile device management, which means Intune.  You also want Azure AD.  That combination pairs your options down to one of two Enterprise Mobility Suite packages (EMS).  Before EMS, Microsoft only offered their products separately such as:

• Azure Active Directory Premium
• Microsoft Intune
• Azure Information Protection
• Microsoft Advanced Threat Analytics

Microsoft then offered EMS combos that bundled features together in a single option for simplicity’s sake.  As of today, there are two EMS bundle offerings which are outlined below:

So what is P1 and P2?  Well P2 includes more advanced features and capabilities.  For instance, the P1 bundle for Azure Active Directory gives you the ability to secure single sign-on to cloud and on premise apps.  It also offers multifactor authentication (MFA) conditional access and advanced security reporting.  P2 includes all of that plus offers Identity Protection and Privileged Identity Management (PIM) and advanced capability concerning identity protection.

E5 of course is more expensive.  So should you get E3 or E5?  Well, just like buying a car, this isn’t a decision that a business should make without a little time and consideration concerning what the needs of the organization actually are, as well as their budget.  Your decision also depends on what other Microsoft cloud services you subscribe to as well such as Office 365.  I told you it was complicated.  If you want to test drive all of the features that E5 has to offer, the good news is that you can sign up for an E5 trial.  That part I can truly say, is easy.

When you join a Windows machine in the traditional way to a network, you have the choice of joining a workgroup or a domain.  A workgroup has limited features.  It really just gives just each device the ability to share files with one another and that is about it.  A domain was a far better choice in most instances because it offers all of the management and security abilities you need in an enterprise.

I use that analogy to describe the difference between MDM Enrollment and Azure Workplace.   Azure Workplace join is not the same as Intune MDM. 

It is however a first step to enrolling in MDM because a device has to joined to Azure AD before it can be enrolled in Intune.  With Azure Workplace, you’re really just “half way there” (as the man to Bon Jovi would say, well, sing really.),

And there is really minimal of advantages to just being "half way" there. 

Azure Workplace is really just about allowing other people to bring their own devices (BYOD) to join your Azure AD and enjoy a few benefits such as:

• single-sign-on (SSO) functionality to cloud services
• access to the Windows store
• ability to logon a device using an organizational work or school account

What you can’t do with Azure Workplace is:

• Deploy applications or
• Manage settings or
• Lockdown a machine
• Wipe it
• Control it. 

All of that takes full MDM enrollment.  But if you are looking for a quick way for a dozen temp workers or contractors to join your Azure AD, it is ample to get the job done.

You can tell if your device is only Azure Workplace joined.  If you click “Manage your account on your Windows Profile page, the page will open in a web browser.  In the screenshot below, you can see where the computer is only “Workplace joined” and not MDM enrolled.

But you can see for yourself if you click on the flag, click Manage your account, and open the page in a Browser, like Edge. You’ll see in Figure 2.23 where the computer is merely “Workplace joined” and not MDM enrolled. 

Note the Windows flag like icon which is also an indicator of Workplace joined status.  If the machine were MDM enrolled, it would be replaced by a briefcase.  In the end, if you want the full Monty, you need to complete the two-part process and become MDM enrolled on top of merely registering with Azure.

I posted this on PolicyPak.. my other blog, but you should check it out anyway. :-)

If you want to know how you stack up against the rest of the world.. here's the blog entry.

Enjoy!

https://www.policypak.com/blog/entry/recent-poll-expansive-use-group-policy.html

I've never met this author, but I like the author's breakdown of the problem.

In summary... I get this question all the time.. "Jeremy... If I disable the UN-used half of the GPO, will it speed up GP processing?"

For 800 years, I've said "Don't bother." You only GAIN headaches because now the other half of the GPO might not process if you end up using it.

Now, a great article with excellent workmanship to prove the point: Don't bother.

https://blogs.technet.microsoft.com/askpfeplat/2018/10/22/does-disabling-user-computer-gpo-settings-make-processing-quicker/

Enjoy the read.

The goal of IT today is to make IT processes as automated as possible so that your IT professionals that are being paid the big bucks don’t have to spend all of their time on trivial tasks such as MDM enrolling devices.  You also don’t want them answering help desk calls all day from users who are confused how to follow the steps on their own that you sent them. 

Well, as you might expect, there is another way.  You can use deep links.  Let’s say you have a new employee with his own BYOD system, and you need their new device to be MDM enrolled.  You send them a nice friendly email that say something like:

Welcome aboard.  We need you to enroll your new Windows 10 laptop.  Please click here to do so.

(Don't worry, that link won't send you to siberia or anything.)

You can check it.. that embedded hyperlink actually points to:

ms-device-enrollment:?mode=mdm

You could also put a link on your company’s portal page and inform users to click the link to enroll a new device.  Clicking this link will launch the flow equivalent to the Enroll into device management option in Windows 10, except it will do the kickoff via the browser.  Note that only Edge and Internet Explorer appear supported however for deep links during my testing. 

Your users still have to input some information. 

Buuuut... If you want to make it even easier for them, you could append their username as a parameter in the link so that it would already be filled in the Email address box.

ms-device-enrollment:?mode=mdm&[email protected]

Note that this option parameter and others are only available in Windows 10, version 1703 or later.

Of course there are more MDM solutions than just Intune.  If you are using Workspace One as your MDM, you may be required to enter a specific server name.  Once again, you can bypass the process of having your users input these specifics in manually by adding the server name parameter.

ms-devicenrollment:?mode=mdm&username=mdm[email protected]&servername=https://techp-ds.awmdm.com

The result would look like this:

Note that there are other optional parameters such as ownership which denotes wheter the device is BYOD or owned by the business enterprise.  Another one is deviceidentifier which passes a unique identifier onto the device.

The point is that Deep Links is made to make it easy and comfortable for users to self enroll themselves.  Self deployment is one of the goals of cloud computing. 

Before you go about adding your first device to Intune, you have to choose your MDM authority for your tenant.  The mobile device management authority determines where you will perform mobile device management tasks.  In a domain joined network, the authority would be either Group Policy or SCCM for instance.  There are three options to configure the tenant-level MDM authority.

1. Intune MDM Authority
2. Configuration Manager MDM Authority
3. None

Intune MDM Authority used to be known as Intune Standalone.  This is a better name descriptor in that using this option, all mobile device management tasks will take place within Intune exclusively.  The second option, Configuration Manager MDM Authority was once known as Hybrid MDM.  Using this option means that devices are managed through a combination of Intune and SCCM Configuration Manager.  You should know that this hybrid ability will be depreciated as of Sept. 1, 2019.  On that date, Microsoft will stop delivering "policy, apps or security updates" to hybrid MDM users.  You can interpret this as strong encouragement by Microsoft to transition to Intune on Azure.  Really, Hybrid Intune was only meant to be a transition state for companies to begin their migrations to the cloud.

Configuring the MDM Authority for your tenant couldn’t be easier.  If you are configuring your MDM Authority for the first time, you can simply logon to the Intune administrator console.  If you are currently running in Hybrid MDM or Configuration Manager MDM Authority, you can either access the Intune administrator console or the Configuration Manager console of your SCCM server to initiate the process.  In this case, I will use the example of assigning the MDM Authority for the very first time.  Once you are logged on, simply go to Device enrollment.

Then you will see the option “Choose MDM Authority.”  Note that if you have assigned your MDM Authority already, this option will not be visible. 

Note that you can only transition from Configuration Manager MDM Authority to Intune MDM Authority and not vise versa.  Also know that while it was true at one time that you had to contact Microsoft support to change from hybrid to stand alone, that requirement is now null and void.  The entire MDM Authority selection process is self serve and simple.  Keep in mind that there may be a transition time involved when changing between the two types of authority modes.  Once the MDM Authority assignment process is complete, you can begin the process of enrolling devices.