Understanding user policy management.
The key to mastering Intune for Education is understanding that policy is filtered through a hierarchy of groups. This is a fundamental difference between MS InTune and Google G Suite.
In G Suite, policy is applied using a simple parent-child folder tree that’s constructed by the admin user. A user or a device (chromebook) can only exist at a single point in the the tree. Policies flow up from the root to the branch of the tree where the object resides. If the user or chromebook is moved from one sub-OU (branch) to another the policies are updated in a consistent and predictable manner.
With InTune you still have a hierarchy but it’s a hierarchy of groups and since an object can exist in many groups it’s possible to create a structure that places an object at multiple points in the tree. While this model provides a level of flexibility that can’t be matched by the Google system it can create extra complexity if you have many groups and many branches in your tree.
For both platforms it’s best to keep it simple but that's particularly true for InTune so let’s see how this might work with out new InTune user Joe Schmoe.
Each InTune group has a built-in tab that lists it’s configuration settings in the same way that the User Chrome Management in the G Suite console presents a list of options.
The major difference between the two approaches is that with Google you navigate to the object you wish to manage (G Mail, Chromebook Devices, Calendar), open the settings tab and then select the point in the OU policy tree you wish the setting to apply..
With InTune the settings are embedded into the group itself and not the service and this creates a number of challenges for the administrator.
The most obvious one is that settings tab must contain a link to every possible value you can set in a policy. At the moment this is fairly manageable but if the list ever expands to anything close to the number of options available to the G Suite admin it could get quite ugly. Fortunately Microsoft has provided a search facility that works in the same way as some of the larger G Suite config lists. I can see this becoming essential.
The situation is compounded by the fact that a group can contain both users and devices and therefore the policy list must contain the settings for both. The settings tab has a pulldown section labelled Windows Device Settings (above) but this also contains user profile settings as well.
First we need to understand the role of the two built-in groups All Devices and All Users which sound like they would sit at the root of your policy tree but of course being Microsoft, they don’t.
Both groups are system defined which means the membership cannot be edited and user defined groups can’t sit above them to inherit policy. So both groups exist in quiet isolation. The main use is to act as the default policy set for any user or device not immediately assigned to a group, a sort of catch-all template policy. If you have a simple setup you can use these groups to push configurations out to your entire estate of users and devices in one easy step which is a great alternative if you wish to avoid the complexities of a group hierarchy.
Nested group policy only applies to user defined groups, so let's create a group called All Students and turn Cortana ON for that user group. You can now create another group called Year 10 as a child of All Students and you’ll see this automatically inherits all the settings of the All Students group with Cortana turned ON. However you can edit the settings for Year 10 to turn Cortana OFF overriding the inherited settings from All Students .
So Joe Schmoe could be in three groups.
To find out whether Joe has access to Cortana you need to know which groups Joe is a member of and how those groups interact. Simply checking that Joe is a member of All Students where Cortana turned is ON tells you nothing because he could be a member of another group higher up the tree where Cortana is turned OFF.
And then it gets really complicated because you also have to consider that the device that Joe is using also has it’s own policy tree which could be completely independent of Joes groups and even fixed to a completely separate group at the root.
So when you turn on the computer is Cortana going to turned ON or OFF?
There’s no way of viewing the resultant set of policy (RSOP) from the console so it’s quite easy for incompatible settings to be applied to the same group. These inconsistencies result in errors when a user or device is being set up with different settings in multiple places.
For example let’s assume Joe is a member of the Year11 group and is also a member of the Geography group. If you configure a homepage setting and assign to Year11, and you configure a different homepage setting and assign it to Geography, Joe has two conflicting homepage settings which leads to an error. Microsoft have thoughtfully provided a report that lists those errors - the group settings errors report.
I suspect any admin trying to implement a fairly complex group hierarchy is going to spend quite a while going through those reports.
Alternatively it might be a better idea to adopt a system that avoids the problem in the first place, so how do you do that?
First understand that although the All Users and All Devices groups are useful tools if you need to differentiate policy between sets of users and devices they are of no real use.
So as a first step create a new root group that represent your school and call it ITE-MySchool for example. Two important things about this group. Preface it with something like ITE so it can be easily identified as a policy group and then invest some time transferring the settings from the All Users group into it as nothing is set by default. Don’t put any users or devices in this group.
Create other groups such as ITE-All Students and ITE-All Staff in the same way.
Organise these groups into a structure that makes applying policy easy to manage using inheritance to do most of the work. Try and set the majority of settings close to the root group.
When you have finished you have created a policy tree but without any objects.
Now drop your production user and device groups (Year 11) at the point of the tree where you want policy to be applied. Unlike the ITE groups you never set policy on these groups that hold users or devices, they are just containers into which the policy flows.
As users are added or removed from the production group the policy will change without any intervention on your part. At the end of year simply move production groups to a new point in the policy tree to allow the inherited policies take effect.
Google admins will recognise this pattern from the G Suite org tree. Working with InTune we are simply replacing sub-organisations for groups and then making sure that a device or user only ever exists within one group in the tree. That way you can ensure consistent results and you have a system that’s far easier to troubleshoot... and it works just like Google.
InTune for Chromebook Admins (p3).
The key to mastering Intune for Education is understanding that policy is filtered through a hierarchy of groups. This is a fundamental difference between MS InTune and Google G Suite.
In G Suite, policy is applied using a simple parent-child folder tree that’s constructed by the admin user. A user or a device (chromebook) can only exist at a single point in the the tree. Policies flow up from the root to the branch of the tree where the object resides. If the user or chromebook is moved from one sub-OU (branch) to another the policies are updated in a consistent and predictable manner.
With InTune you still have a hierarchy but it’s a hierarchy of groups and since an object can exist in many groups it’s possible to create a structure that places an object at multiple points in the tree. While this model provides a level of flexibility that can’t be matched by the Google system it can create extra complexity if you have many groups and many branches in your tree.
For both platforms it’s best to keep it simple but that's particularly true for InTune so let’s see how this might work with out new InTune user Joe Schmoe.
Each InTune group has a built-in tab that lists it’s configuration settings in the same way that the User Chrome Management in the G Suite console presents a list of options.
The major difference between the two approaches is that with Google you navigate to the object you wish to manage (G Mail, Chromebook Devices, Calendar), open the settings tab and then select the point in the OU policy tree you wish the setting to apply..
With InTune the settings are embedded into the group itself and not the service and this creates a number of challenges for the administrator.
The most obvious one is that settings tab must contain a link to every possible value you can set in a policy. At the moment this is fairly manageable but if the list ever expands to anything close to the number of options available to the G Suite admin it could get quite ugly. Fortunately Microsoft has provided a search facility that works in the same way as some of the larger G Suite config lists. I can see this becoming essential.
The situation is compounded by the fact that a group can contain both users and devices and therefore the policy list must contain the settings for both. The settings tab has a pulldown section labelled Windows Device Settings (above) but this also contains user profile settings as well.
For the full confusion effect if you open the settings tab for the built in All Users groups you are still only presented with the Windows Device Settings pull down. Renaming it to Windows Settings would help as would breaking the policies into two discrete sets in the same way that G Suite works.Which brings me to the next point. Because the policies are mixed it’s difficult to know which are controlled by the user object and which by the device object. If Cortana is turned ON by group user policy but then turned OFF by a Device group policy in a higher level group, which takes precedence? Where this gets really hard to comprehend is when both the user and device are members of two entirely different policy trees and so you’re unable to use the position in the tree to work it out. Let’s see how this could happen and what you can do to avoid it..
First we need to understand the role of the two built-in groups All Devices and All Users which sound like they would sit at the root of your policy tree but of course being Microsoft, they don’t.
Both groups are system defined which means the membership cannot be edited and user defined groups can’t sit above them to inherit policy. So both groups exist in quiet isolation. The main use is to act as the default policy set for any user or device not immediately assigned to a group, a sort of catch-all template policy. If you have a simple setup you can use these groups to push configurations out to your entire estate of users and devices in one easy step which is a great alternative if you wish to avoid the complexities of a group hierarchy.
Nested group policy only applies to user defined groups, so let's create a group called All Students and turn Cortana ON for that user group. You can now create another group called Year 10 as a child of All Students and you’ll see this automatically inherits all the settings of the All Students group with Cortana turned ON. However you can edit the settings for Year 10 to turn Cortana OFF overriding the inherited settings from All Students .
So Joe Schmoe could be in three groups.
- All Users - Cortana turned OFF.
- All Students - Cortana turned ON.
- Year 10 - Cortana turned OFF.
To find out whether Joe has access to Cortana you need to know which groups Joe is a member of and how those groups interact. Simply checking that Joe is a member of All Students where Cortana turned is ON tells you nothing because he could be a member of another group higher up the tree where Cortana is turned OFF.
And then it gets really complicated because you also have to consider that the device that Joe is using also has it’s own policy tree which could be completely independent of Joes groups and even fixed to a completely separate group at the root.
So when you turn on the computer is Cortana going to turned ON or OFF?
There’s no way of viewing the resultant set of policy (RSOP) from the console so it’s quite easy for incompatible settings to be applied to the same group. These inconsistencies result in errors when a user or device is being set up with different settings in multiple places.
For example let’s assume Joe is a member of the Year11 group and is also a member of the Geography group. If you configure a homepage setting and assign to Year11, and you configure a different homepage setting and assign it to Geography, Joe has two conflicting homepage settings which leads to an error. Microsoft have thoughtfully provided a report that lists those errors - the group settings errors report.
I suspect any admin trying to implement a fairly complex group hierarchy is going to spend quite a while going through those reports.
Alternatively it might be a better idea to adopt a system that avoids the problem in the first place, so how do you do that?
First understand that although the All Users and All Devices groups are useful tools if you need to differentiate policy between sets of users and devices they are of no real use.
So as a first step create a new root group that represent your school and call it ITE-MySchool for example. Two important things about this group. Preface it with something like ITE so it can be easily identified as a policy group and then invest some time transferring the settings from the All Users group into it as nothing is set by default. Don’t put any users or devices in this group.
Create other groups such as ITE-All Students and ITE-All Staff in the same way.
Organise these groups into a structure that makes applying policy easy to manage using inheritance to do most of the work. Try and set the majority of settings close to the root group.
When you have finished you have created a policy tree but without any objects.
Now drop your production user and device groups (Year 11) at the point of the tree where you want policy to be applied. Unlike the ITE groups you never set policy on these groups that hold users or devices, they are just containers into which the policy flows.
As users are added or removed from the production group the policy will change without any intervention on your part. At the end of year simply move production groups to a new point in the policy tree to allow the inherited policies take effect.
Google admins will recognise this pattern from the G Suite org tree. Working with InTune we are simply replacing sub-organisations for groups and then making sure that a device or user only ever exists within one group in the tree. That way you can ensure consistent results and you have a system that’s far easier to troubleshoot... and it works just like Google.
InTune for Chromebook Admins (p3).
No comments:
Post a Comment