For schools looking to take advantage of cloud services first step is often the adoption of either Google G Suite for Education or Microsoft Office365 and the integration with on premise user database which, for the UK at least normally means Microsoft Active Directory.
For this reason there are a lot of Microsoft trained network administrators who are coming across the Google Administration console for the first time and wondering how to transfer their experience and knowledge to this new environment.
On the face of it there seem to be some similarity between the two systems.
Possibly not in the layout and operation of the management console but certainly in the way the organisation is logically structured. Both systems have a top level object which represents the school or district and the ability to create nested hierarchy of smaller units that you can use to make the administrative process easier.
Microsoft calls these units Organizational Units while in the Google world the correct term is Sub Organisations although the abbreviation OU seems to have been commonly adopted for both in posts and blogs so we’ll stick with that.
Microsoft and Google OU’s have a good deal in common.
Unfortunately the two systems also have some basic differences and this is where the confusion can set in.
In the Microsoft world policies are contained in object’s called GPO’s (Group Policy Objects).
Once defined a single GPO can be associated with a single OU, multiple OU’s or no OU’s at all. Changing the GPO in one location changes for all other linked OU’s. Therefore in the Microsoft world a policy is an independent entity which can have ‘one to many’ relationship with the underlying OU structure.
In the Google world policies and OU’s are one and the same thing.
Unlike Microsoft GPO’s they are not independent of each other. Inheritance can appear to transfer settings up the tree but this doesn’t alter the fact that every Google OU has it’s own policy set which applies to that OU and no other.
Both approaches have the strength and weakness. The Microsoft one-to-many approach provides greater flexibility but can also lead to a level of complexity that takes an additional tool just examine the policy set for any one object ( the Resultant Set of Policy mmc snap-in).
The adaptability of the Microsoft approach allows the AD administrator to create an OU hierarchy which does not necessary reflect how the policies are set. Policies can be blocked, set across multiple branches and be retrospectively applied. A Microsoft admin can create an OU tree which reflects a geographic or administrative infrastructure and then, with some limitations layer a workable policy scheme over the top at a later stage.
In contrast the Google OU hierarchy IS the policy scheme and for this reason the two approaches are fundamentally different.
As a consequence it's rarely the case that the hierarchy created for an AD domain is a suitable model for the Google OU tree and administrators shouldn’t try and replicate it to a Google organisation without giving it some thought as to exactly what they are trying to achieve.
While we are on the subject of similarities and differences there are others that are worth mentioning.
Just like a Microsoft OU, a Google OU can contain users and devices but not other common objects such as groups, contacts and calendar resources. These items exist but are not managed within the OU structure.
A Google OU hierarchy has direct relationship with network services such as mail, drive and the user application set. Allocating and deallocating these resources is far easier in the Google world.
Lastly because Google maintains the backend infrastructure, the management console can be presented as a simplified set of services that can be turned on and off at the OU level. For a school administrator this is a far easier concept to understand than the Microsoft model which has to expose the underlying infrastructure using objects such as networks, servers and data connectors with configurations and controls at each level.
So where does that leave the Microsoft sysadmin?
From my experience the immediate reaction of most AD administrators to the Google admin console is either dismay at its apparent simplicity or frustration at not being able to work at a ‘lower level”.
However this is misconception. The Google console still has enough subtlety to trip up the most confident Microsoft admin as well as an API powerful enough to meet the requirements of the most hard-core powershell addict.
With a bit of effort it can be made complicated, so there's still hope.
For this reason there are a lot of Microsoft trained network administrators who are coming across the Google Administration console for the first time and wondering how to transfer their experience and knowledge to this new environment.
On the face of it there seem to be some similarity between the two systems.
Possibly not in the layout and operation of the management console but certainly in the way the organisation is logically structured. Both systems have a top level object which represents the school or district and the ability to create nested hierarchy of smaller units that you can use to make the administrative process easier.
Microsoft calls these units Organizational Units while in the Google world the correct term is Sub Organisations although the abbreviation OU seems to have been commonly adopted for both in posts and blogs so we’ll stick with that.
Microsoft and Google OU’s have a good deal in common.
- Both systems can be used to create a tree-like structure to organise users and devices for management purposes.
- Management policies are linked to this tree structure, each OU inheriting settings from it’s parent object in a similar way.
- In both systems a user or device can only be contained within a single OU and moving objects between OU’s can directly affect the policies applied to that object.
Unfortunately the two systems also have some basic differences and this is where the confusion can set in.
In the Microsoft world policies are contained in object’s called GPO’s (Group Policy Objects).
Once defined a single GPO can be associated with a single OU, multiple OU’s or no OU’s at all. Changing the GPO in one location changes for all other linked OU’s. Therefore in the Microsoft world a policy is an independent entity which can have ‘one to many’ relationship with the underlying OU structure.
As an example if you could create a simple GPO to set the wallpaper for a client session and link it to multiple OU’s, on any branch and at any level. If you update the policy for one OU the change will apply all the other OU’s linked to the policy.
In the Google world policies and OU’s are one and the same thing.
Unlike Microsoft GPO’s they are not independent of each other. Inheritance can appear to transfer settings up the tree but this doesn’t alter the fact that every Google OU has it’s own policy set which applies to that OU and no other.
Both approaches have the strength and weakness. The Microsoft one-to-many approach provides greater flexibility but can also lead to a level of complexity that takes an additional tool just examine the policy set for any one object ( the Resultant Set of Policy mmc snap-in).
The adaptability of the Microsoft approach allows the AD administrator to create an OU hierarchy which does not necessary reflect how the policies are set. Policies can be blocked, set across multiple branches and be retrospectively applied. A Microsoft admin can create an OU tree which reflects a geographic or administrative infrastructure and then, with some limitations layer a workable policy scheme over the top at a later stage.
In contrast the Google OU hierarchy IS the policy scheme and for this reason the two approaches are fundamentally different.
As a consequence it's rarely the case that the hierarchy created for an AD domain is a suitable model for the Google OU tree and administrators shouldn’t try and replicate it to a Google organisation without giving it some thought as to exactly what they are trying to achieve.
While we are on the subject of similarities and differences there are others that are worth mentioning.
Just like a Microsoft OU, a Google OU can contain users and devices but not other common objects such as groups, contacts and calendar resources. These items exist but are not managed within the OU structure.
A Google OU hierarchy has direct relationship with network services such as mail, drive and the user application set. Allocating and deallocating these resources is far easier in the Google world.
Lastly because Google maintains the backend infrastructure, the management console can be presented as a simplified set of services that can be turned on and off at the OU level. For a school administrator this is a far easier concept to understand than the Microsoft model which has to expose the underlying infrastructure using objects such as networks, servers and data connectors with configurations and controls at each level.
So where does that leave the Microsoft sysadmin?
From my experience the immediate reaction of most AD administrators to the Google admin console is either dismay at its apparent simplicity or frustration at not being able to work at a ‘lower level”.
However this is misconception. The Google console still has enough subtlety to trip up the most confident Microsoft admin as well as an API powerful enough to meet the requirements of the most hard-core powershell addict.
With a bit of effort it can be made complicated, so there's still hope.
No comments:
Post a Comment