MDM & GP Tips Blog

Jan 2019
25

Creating ADMX-backed policies is hard in Intune. Here's some guides to help you.

I have to admit... making a simple registry change in Intune can be ... difficult. 

The Administrative Templates function is nice, for those (under 300 settings) that support them. 

But for the rest of the simple settings ... you might have hand-create custom OMA-URIs and usin ADMX backed policies to do it.

Here are some others' great guides to help you "follow the leaders" and convert your ADMX and/or use an ADMX-backed policy:

Those resources, show how to tear into an ADMX and ADML file and create a more complex ADMX-backed policy:

  • https://docs.microsoft.com/en-us/windows/client-management/mdm/understanding-admx-backed-policies
  • https://docs.microsoft.com/en-us/windows/client-management/mdm/enable-admx-backed-policies-in-mdm
  • https://www.petervanderwoude.nl/post/allow-users-to-connect-remotely-to-this-computer-via-windows-10-mdm-admx-style/
  • https://www.petervanderwoude.nl/post/deep-dive-configuring-windows-10-admx-backed-policies/
  • http://carlbarrett.uk/admx-backed-policies-quickish-reference-guide
  • http://thesccm.com/use-intune-policy-csp-manage-windows-10-settings-internet-explorer-site-to-zone-assignment-list/

 

Jan 2019
22

Office 2016 ADMX templates, seemingly broken for Outlook ADMX

I got a tip from Pat DiPersia at www.dipersiatech.com and Susan Bradley, MVP about this one.

In short, I tested it myself, but the latest Office 2016 ADMX files seem to have got a messed up XML tag, rendering the Outlook policy useless. I tested both the 32 and 64 bit templates. They both have problems with Outlook.

I've reached out to report this issue.

At least now you know if you're trying it yourself... you're not crazy !

The error when adding to your Policy store looks like this after you click on Admin Templates.

TIP:

The issue is the /policies closing tag is before the final /policy closing tag.  Looks like someone added a policy after the fact, and didn’t put it in the right spot.  The /policies tag on line 6285, should be on line 6296 (Followed by /policydefinitions.) See screenshot below.

Jan 2019
17

Intune’s new ADMX and Admin Template Support

This week an Intune feature I have been playing with for a while has finally gone live for Preview.
It’s called “Administrative Templates” and … oh wow, that sounds a lot like Group Policy Administrative Templates, and, oh yes. You’re right… mostly.

Now, before you go bananas saying “Jeremy, clearly Intune now has total Group Policy support!” Or, worse, beat the old trope that “Group Policy must be dead.”

As anything new, it’s worth investigation and to ensure it does what you think it’s going to do.

Let’s talk about the good stuff first !

So, to set the stage, you have to first understand what ADMX backed settings are within Intune / MDM.
It starts with the idea that some settings which are curated by the MDM team. Now, this is weird so stick with me. Because the MDM team is not the Intune team.
You can think of the MDM team as the “receiving platform” which decides upon the settings within the platform.

You can think of the Intune team as “expressing” those settings with knobs and buttons. And this is because Intune isn’t the only MDM game in town; for instance, VMware Workspace one, MobileIron, SOTI and others.

So, these ADMX-backed settings are, as you can imagine, real Group Policy settings which are supported by the target application, say, Explorer or Office.

But these settings are curated by the MDM team as “guaranteed to work and supported as such.”

If you want to see the official docs on Administrative Templates feature you can find it here: https://docs.microsoft.com/en-us/intune/administrative-templates-windows
Here’s the best part from the docs:

These templates are similar to group policy (GPO) settings in Active Directory (AD), and are ADMX-backed settings that use XML. But, the templates in Intune are 100% cloud-based. They offer a more simple and straight-forward way to configure the settings, and find the settings you want.

This is really nice. What’s not to like? Indeed, if you wanted to achieve these ADMX-backed settings before this feature came to be, you needed to know how to perform the dark arts of custom OMA-URI (a different topic for a different day.) Now, with Administrative Templates in Intune, for all those settings, those values are just click and go. +1 for that !

If you look at the docs, you’ll see the following line:

The administrative templates include hundreds of settings that control features in Internet Explorer, Microsoft Office programs, remote desktop, access to OneDrive, use a picture password or PIN to sign in, and more.

The key word here is hundreds. Why is it hundreds, and not thousands or “all”?

Well, you need to go back to something I said earlier. All settings in MDM (and by extension, Intune) are curated. Each setting must be vetted to work as expected and then guaranteed by the MDM platform.

Also, at last count the number of exposed Administrative Template settings is 237. (Note: I did not re-count it before publishing this; the number could have gone up somewhat.). As the docs state, most of the settings seem to revolve around Office, OneDrive, Internet Explorer, and a handful of system settings.

As such you will likely see this list grow over time, but my understanding is that this is not meant to overtake or subsume all existing Group Policy settings.
If you are looking for a setting which doesn’t exist in Intune.. either a native clickable one or via Administrative Templates, don’t despair or throw in the towel, yet.

If you want to make any real Group Policy, Group Policy Security and/or Group Policy Preference setting work thru Intune, you need to enhance Intune with a 3rd party tool. Here's a video for how it's done. An equallty effective option is to use this other 3rd party option, which works with MDM or whenever there is no MDM present.

Let’s talk about what’s missing, last.

If you get a chance to play with this feature, click upon Intune | Device Configuration | Profiles | Create Profile and select Administrative Templates (Preview) like what’s seen here.

Then under Settings, you will see the list of Administrative Template settings like what’s seen here.
Top of the page…

Bottom of page….

At the top of the page begins an alphabetical list of the curated ADMX policy settings and a Search (Filter) bar.
So, if you wanted to quickly search of OneDrive, you can find those settings.
But what you cannot do, like Group Policy, is see these settings hierarchical.

I can see both sides of this; this flat view reduces clutter. But my preference would be to see the settings hierarchical, so I could maybe find related settings around the primary setting I’m searching for.

Summary about Admin Templates in Intune

In summary, Administrative Templates a nice step forward in Intune. Just know that it’s not designed to attempt to take on all of Group Policy settings, but be on the lookout for increased coverage over the long haul as new interesting scenarios pop-up.

Jan 2019
07

Cortana now quiet with Windows OOBE except for Windows Home (important for Autopilot)

Starting in Windows build 18309, Cortana doesn't start talking "at you."... unless you're using Windows Home.

Why is this important? Well, check out this (hysterical) video for why not ...

https://youtu.be/Rp2rhM8YUZY

Before this you had to set a registry key. I've updated the Microsoft docs to reflect the change. :-)

https://docs.microsoft.com/en-us/windows-hardware/customize/desktop/cortana-voice-support 

Dec 2018
19

Why you can use LAPS and banish logging on as Domain Admin when doing remote help

So, okay.. you don't want to log on with your Domain Admin credentials to Mr. End User's machine.

Doing so increases the risk of Pass the Hash attacks.

My pal Aaron Margosis from Microsoft shows how you can use Group Policy to block logins from anyone EXCEPT local admins.

AND, because you're using LAPS to maintain local admin passwords, only that account can log on.

Brilliant.

Here's the blog entry to increase your security:

https://blogs.technet.microsoft.com/secguide/2018/12/10/remote-use-of-local-accounts-laps-changes-everything/

 

Dec 2018
11

What is ADMX File Ingesting in Intune?

What is ADMX File Ingesting in Intune?

 

We’ve talked about how Intune has incorporated ADMX backed policies to manage even more settings in your Windows 10 devices.  But what if you want to deliver settings that aren’t part of the “in the box” policies from Microsoft.  Well, if you are familiar with Group Policy, then you are aware that you can garner more policy setting opportunities by importing new ADM or ADMX files.  For instance, Microsoft Office has an ADMX file as does other third party applications such as Adobe Reader and to some extent, Mozilla Firefox.   Well you can import additional ADMX files for MDM as well, although its currently not as easy as there is no central store for MDM like is the case for Group Policy.  There is no way (at present) to add additional ADMX templates with a couple clicks of the mouse, but with just a little bit of trouble, you can do it.

The process of importing ADM or ADMX files into MDM is called “ingesting.”  The ingesting process goes like this:

  • We create a Custom Windows 10 policy
  • We ingest the custom ADMX through the Policy CSP
  • We apply the settings we want to enforce

So how do we ingest an ADMX file?  Well, in this case, ingesting means copy/paste.  You obtain the ADMX file you need and then open it in some type of editor such as Notepad.  For this example, I’m going to use the OneDrive.admx file.  I’m not going to show what the entire file looks like in Notepad, but here is what the first part of it looks like:


    
As discussed earlier, creating a custom policy means creating a Custom OMA-URI.  To ingest an ADMX file we must use the following format:

./Vendor/MSFT/Policy/ConfigOperations/ADMXInstall/{AppName}/{SettingType}/{AdmxFileName}. 

I don’t want to get into the boring details concerning the naming of these variables.  Just follow the basic guideline that you should assign the (setting type) variable as “policy” and the other two variables should be meaningful names such as the actual name of the App and the actual name of the ADMX file.  You can name them anything you want actually but its always best to use names that are intuitive for other personnel.  In the case of our OneDrive ADMX example, that would translate to this:

./Device/Vendor/MSFT/Policy/ConfigOperations/ADMXInstall/OneDrive/Policy/OneDriveAdmx

As you mentioned, copy the entire contents of the opened ADMX file in Notepad and paste it into the value text box as shown below:

Once the new profile is created, we can then use it to deliver the new supported settings using that profile.   

Dec 2018
07

Azure and Intune Assigned Groups

One of the principles of proper AD administration is to congregate your users into groups to make it easier to assign permissions and rights.  We use groups within Intune as well for this same reason.  In this case, Intune uses Azure AD to manage access to your company’s resources which is controlled using roles in the directory.  There are two default groups within every implementation of Intune.

  • All devices
  • All users

If you are using Intune for Education and you use School Data Sync to import you school records, you have two additional default groups.

  • All teachers
  • All users

These default groups represent a very broad scope and by themselves probably aren’t of much use.  That is why we need to create custom groups that can be tailored to the needs of our organization. There are two types of custom created groups in Intune, one being Assigned Groups.  Assigned groups are used when you want to manually add specific users or devices to a group.  You can create groups by a number of criteria such as geographic location, department, hardware characteristics, etc.  For instance, you could create one assigned group for your Windows 10 devices and one for your iPads.  You could create one for your desktop PCs and one for your mobile devices.  You can separate users into separate groups as well such as HR, Finance and Marketing.  You can then use those groups to assign policies to users or deploy apps to a set of devices.  Note that the ability to create custom groups is available in any MDM service, not just Intune.

Creating a group is easy.  Go to the Groups section of Intune and click “New Group.”  Then add the required information for that group.  In this case we would select “Assigned” as the membership type. 

Once the group is made, you can then assign users to that group.  Note that just as in domain joined AD, you can nest groups within one another.  These subgroups can be used to break down large groups into smaller more manageable sizes.  Groups have a hierarchical structure to them in Intune which allows for inheritance.  Parent groups are at the top of the hierarchy and any settings applied to these parent groups are passed down to the subgroups.  This settings inheritance feature makes it easer to apply settings to large numbers of users and devices.  Know that you can only create subgroups under assigned groups.

Dec 2018
04

Azure and Intune Dynamic Groups

So Assigned Groups are great and there are many uses for them.  But we live in a dynamic world today and our Azure/Intune environments are often reflective of that.  Things change, and sometimes we need our groups to adapt to those changes.  That is why we also have Dynamic Groups.  Rather than specifying the users or devices to add to a group, we set criteria to define the members of a Dynamic Group.   When the specified condition applies for a user or device, it is added to the group automatically.  Should a member no longer satisfy the rule, it is removed from the group.  The use of Dynamic Groups can greatly reduce the administrative overhead of constantly adding and removing users for large enterprise environments that perpetually change.

There are a couple of things that are different when creating Dynamic Groups.  First off, P1 or P2 licensing is required to create and use Dynamic groups.  Second of all, we must make separate groups for users and devices as is shown below.

Once we create our Dynamic Group, we need to populate it.  Remember, we don’t select the users or devices ourselves.  We cannot manually add or remove a member from a Dynamic group.  We create membership rules which will then populate the groups by querying Azure AD to find the members that meet the criteria of that rule.  Make note again that we cannot create a rule that contains both users and devices.

There are two types of rules, Simple and Advanced.  I assume everyone wants to start with the easier one first so let’s create a Simple Rule.

A membership rule has 3 components:

  • A property
  • An operator
  • A value

Say we wanted to create a dynamic group to include all current users of the HR Department.  In this case the property would be “department,” the operator would be “equals,” and the value would be HR.  If this isn’t sounding very simple, think again, because the Simple Rule creator interface does a great job of guiding you through the process.  You just simply choose which option you want from each component menu.  This of course means that your rules are limited to the choices made available in the GUI.

So what about Advanced Rules?  Well sometimes you may want to run extensive queries that go beyond the confines of the Simple rule creation process.  Creating Advanced rules may look a little intimidating because there is no easy to follow GUI menu to guide you.  Instead you only get a text box where you write out your rule.  Actually its not that intimidating.  We could have created an Advanced rule for our previous example for those users who belong to the HR Department.  The “rule equation” per say would be as follows:

(user.department -eq "HR")

A good example of when you might need to use an Advanced rule would be if you are applying multiple criteria in a single rule.  For instance, you want to create a Dynamic device group for Windows 1809 devices.  In this example, the rule would have to first query for Windows devices and then perform a subsequent query for the build number, which in this case is “10.0.17758.”  The resulting rule would then be as follows:

(device.deviceOSType -eq “Windows”) -and (device.deviceOSVersion -startsWith “10.0.17758”)