Managing application access through the organisational tree in G Suite is both a blessing and a curse.
On the plus side it’s a simple, easy to use framework which has proven extremely effective in deploying dozens of applications across thousands of user accounts with minimal management overhead.
On the minus side it has one major weakness that has been detailed in a number of posts. The organisational tree cannot support a situation in which a user is a member of many different sets. For this reason it’s not possible to deploy an app to just the students in the History Class in Year 10. To deploy an app to a subject set you need a one-to-many relationship and that can only be done through groups.
Other platforms such as InTune for Education use this approach as do many other MDM platforms including Google's Mobile Manager. That’s not to say groups don't create their own unique management issues but the point remains that to deploy subject based apps you need groups.
Fortunately allowing groups to control app deployment is a feature that has recently made an appearance in the G Suite Management console. So are the problems solved ?
The first thing to know is that the type of group used to control app deployment cannot be defined using Google Groups for Business (GG4B) but must be created using either the Groups icon within the admin console or through the Directory API. For this reason groups maintained using Google Cloud Directory Sync and most other third party products will work fine. Once created they can be managed through GG4B. Nested groups are supported.
The second thing is that groups can only be used to turn apps ON. This means that groups only have an effect if the sub-OU holding the user account sets the app to OFF. In this case the group setting (ON) overrides the sub-OU setting (OFF).
This might sound a bit limiting but that's not really the case.
Let's take a few examples.
Task 1: You need to turn on Blogger/Sites/Hangouts for a 6th form Media Class that contains user accounts held in a number of different sub-OU’s. The default action is set lower down the tree and turns these items OFF for all students. Prior to groups this was a big problem. You could either turn it ON for students or tie yourself in knots creating sub-OU’s. Now you can just create a new access group called app_Media_Group drop and turn on whatever apps you need for that group.
Task 2: You’ve been asked to trial Classroom in your school. You need to grant access to two teachers who’ll be taking the English class and a member of the SLT team. The problem here is the teachers reside in an sub-OU with all the other teachers, the SLT team are in the parent OU and the students in a complete different part of the tree with 60 other accounts. You consider the OU approach before realising that one of the students is already residing a sub-OU Penalty Box and can’t be be moved. Groups to the rescue again.
While we are on the subject of a Penalty Box it might seem like a good idea to allow groups to turn apps OFF as well as ON to cover exactly this scenario but when you consider ease of use that may not be the case. Flexibility often brings more complexity and in this case I believe Google got it exactly right because even with the added group filter it’s still pretty to work out what policy applies to which app.
In this example we have turned Jamboard OFF for all users at the root but then enabled it for the group called groupwithbusinessoff.
The console immediately shows it as ON for some with the View Details link to break out the information you need.
To examine the apps from the user perspective you can use the Apps card on the user account dialog.
Dropping the user account into the groupwithbusinessoff group shows the app being applied for that single user.
Like most of what Google does, application control through groups is a simple idea that’s been well implemented, but could it be better?
At the moment groups can only be applied for G Suite and Additional Google Services but not Marketplace apps which are more likely to be subject based. Also there's no sign yet of group based deployment from the Chrome Store which would be a real breakthrough.
Lastly since membership of a group can now enable an app, why not a Google Classroom.
Now there’s an idea, over to you Google.
On the plus side it’s a simple, easy to use framework which has proven extremely effective in deploying dozens of applications across thousands of user accounts with minimal management overhead.
On the minus side it has one major weakness that has been detailed in a number of posts. The organisational tree cannot support a situation in which a user is a member of many different sets. For this reason it’s not possible to deploy an app to just the students in the History Class in Year 10. To deploy an app to a subject set you need a one-to-many relationship and that can only be done through groups.
Other platforms such as InTune for Education use this approach as do many other MDM platforms including Google's Mobile Manager. That’s not to say groups don't create their own unique management issues but the point remains that to deploy subject based apps you need groups.
Fortunately allowing groups to control app deployment is a feature that has recently made an appearance in the G Suite Management console. So are the problems solved ?
The first thing to know is that the type of group used to control app deployment cannot be defined using Google Groups for Business (GG4B) but must be created using either the Groups icon within the admin console or through the Directory API. For this reason groups maintained using Google Cloud Directory Sync and most other third party products will work fine. Once created they can be managed through GG4B. Nested groups are supported.
The second thing is that groups can only be used to turn apps ON. This means that groups only have an effect if the sub-OU holding the user account sets the app to OFF. In this case the group setting (ON) overrides the sub-OU setting (OFF).
This might sound a bit limiting but that's not really the case.
Let's take a few examples.
Task 1: You need to turn on Blogger/Sites/Hangouts for a 6th form Media Class that contains user accounts held in a number of different sub-OU’s. The default action is set lower down the tree and turns these items OFF for all students. Prior to groups this was a big problem. You could either turn it ON for students or tie yourself in knots creating sub-OU’s. Now you can just create a new access group called app_Media_Group drop and turn on whatever apps you need for that group.
Task 2: You’ve been asked to trial Classroom in your school. You need to grant access to two teachers who’ll be taking the English class and a member of the SLT team. The problem here is the teachers reside in an sub-OU with all the other teachers, the SLT team are in the parent OU and the students in a complete different part of the tree with 60 other accounts. You consider the OU approach before realising that one of the students is already residing a sub-OU Penalty Box and can’t be be moved. Groups to the rescue again.
While we are on the subject of a Penalty Box it might seem like a good idea to allow groups to turn apps OFF as well as ON to cover exactly this scenario but when you consider ease of use that may not be the case. Flexibility often brings more complexity and in this case I believe Google got it exactly right because even with the added group filter it’s still pretty to work out what policy applies to which app.
In this example we have turned Jamboard OFF for all users at the root but then enabled it for the group called groupwithbusinessoff.
The console immediately shows it as ON for some with the View Details link to break out the information you need.
To examine the apps from the user perspective you can use the Apps card on the user account dialog.
Dropping the user account into the groupwithbusinessoff group shows the app being applied for that single user.
Like most of what Google does, application control through groups is a simple idea that’s been well implemented, but could it be better?
At the moment groups can only be applied for G Suite and Additional Google Services but not Marketplace apps which are more likely to be subject based. Also there's no sign yet of group based deployment from the Chrome Store which would be a real breakthrough.
Lastly since membership of a group can now enable an app, why not a Google Classroom.
Now there’s an idea, over to you Google.
No comments:
Post a Comment