Often times the initial decisions we make have long-standing effects on our environment and can result in unforeseen consequences. One of the first decisions we make within the Google Ecosystem is how to logically layout the OU Structure within G Suite.
For those of us who came from an Active Directory environment, it may seem reasonable to mirror our Google OU structure to match the AD environment. This is especially tempting when automation tools released by Google support this behavior out of the box. Maybe your Student Information Systems offers G Suite provisioning, but after implementing the automation, you find that due to the rigidness of the OU Structure, you are spending unnecessary time configuring the same setting across multiple OUs (and possibly missing an OU by accident). Perhaps instead, you inherited the OU Structure from a previous administrator and can only guess what they were thinking when they set things up.
Regardless of how your OU Structure got the way it is, often we find that there is a need to change this structure. Amplified IT recommends an OU Structure for optimal management of G Suite that has a main division off the root of Staff and Students since this is where the majority of settings and service differences will be made. From there, dividing each into the widest next level decision for each category, (like School Level, School Name, Grade, etc) and so on until you are at your User’s container. Below is an example of this recommended structure.
Just as when initially configuring your OU Structure, consideration needs to be given to the effect of changing your OU structure. What will happen when you move an Org Unit out of the current location to a new location? Would simply moving things around give the desired results? Not necessarily. If previously you had a structure where local settings were applied to each building’s student OU those locally applied settings will remain in effect. If all settings were previously inherited from a parent OU, none of the prior settings would necessarily be carried over.
Knowing where settings are locally applied and how inheritance is working is an important step in the planning process if the desired result is that all current settings are carried over. For those wanting to have a snapshot, Amplified IT’s support team can assist in generating a report of most Locally applied settings and services for support customers.
If you have automation that is handling the creation and deletion of the OU Structure, ensure that that the deletion of Org Units is paused before you make any changes to your G Suite OU structure. If you do not you may lose not only your new structure but all the configured settings.
What the desired outcome of an OU Restructure? If current settings are less of a concern, the easiest method for updating the OU Structure is to simply start anew. Using this approach, you would create the ideal OU structure by starting from scratch. Alternatively, if the desire is to have as little change visible to end users, it may be better to move existing Org Units with their existing settings and rename them appropriately.
When deciding whether to start fresh or move and rename, take into consideration some new abilities that Google has implemented around Services – the ability to enable a Service based on Group membership. Where previously it was required to turn Vault on for all users in an Org Unit to give them access to the Google Vault interface, now we can disable it for everyone, except members of a specific Google Group. This can also be done for additional Apps and Services like Google Development Console, Google Payments or Google Takeout, to name a few, which absolutely have merit using this new-found availability. Though the Service is enabled by Group membership, Settings within the services still are configured on the users’ OUs.
Starting from scratch or moving and renaming may not be the perfect solution for all deployments. Consider that there are settings which are cumbersome to implement – for example, a per OU Custom WebStore and PlayStore configurations. There may be hundreds of Apps that have been permitted, blocked, or recommended and there is no easy way to copy these settings from one OU to another. This leads to a hybrid solution – moving and renaming Org Units to where their locally applied settings would fit in the ideal OU Structure, and then creating the new OUs where settings are expected to be fully inherited.
The school had been organized into groups of people by the building which they were located. The OUs were then separated by staff and student status below the building. This required configurations to be made on each student OU. All student OUs had the same or very similar settings configured.
An OU has all desired policies configured for the majority of student OUs. This OU should be the /Students organizational unit. Then create new OUs for each building. Under each building create new OUs for each grade level. This will result in all of these new OUs inheriting policies from the new /Students OU. Exceptions can then be made at the appropriate level.
Regardless of which solution fits your situation best, we’re not done yet. Whatever method you use to get to the desired Org Unit structure, you now need to ensure that automation and third parties are functioning as desired. You may find that your current automation doesn’t provide the flexibility to use the new OU Structure. In this case, it might be time to find an option that supports more granular flexibility.
If your users exist in Active Directory, Google Cloud Directory Sync (GCDS) offers flexible mapping based on LDAP queries. Each Google OU will have at least one rule that maps the results of the LDAP query to that Org Unit. If you would prefer to sync directly from your SIS, or any other authoritative source (including AD), Amplified IT has developed a tool called GFE Sync which offers a very flexible alternative to other provisioning tools.
And finally, third-party services that connect to your G Suite environment will need to be updated. If you use a tool like Securly or GoGuardian for content filtering, or SysCloud for backup or Content Compliance, make sure that you pull down your new OU Structure and apply the appropriate filtering policies to the new structure. Failure to do so can result in these third party tools not functioning as expected.
If you would like to get additional information or assistance on correcting your OU Structure, contact us or visit our support page to find out other ways we can assist you with technical projects within your Google for Education environment.
Find this article useful? Share it!
Technical Support Analyst
About the Author:
Stephen lives in Utah and enjoys the puzzle of investigating users’ problems and finding potential solutions. A recovering / reformed Gamer, Stephen throws himself into his passion for staying on top of all things Chrome OS and Chromebook related. Prior to joining Amplified IT, Stephen served as a Network Admin in a Therapeutic Boarding School and an IT director, where he implemented G Suite for Education. Stephen has studied computer science and security at Weber State University, Western Governors University. A self-anointed honor, Stephen likes Chromebooks more than almost anyone else in the world.