Working with Google Cloud Directory Sync (GCDS) and Classroom it's possible to synchronize with multiple group owners.
This might be well known fact but I can't find it documented anywhere and I think it might be useful to others.
The plan was to use GCDS to import AD groups that defined the class sets to be used with Classroom. The import created about 200+ groups across all years and subject areas and staff members were keen to start creating classes based on the group membership.
The problem arose when staff attempted to invite class members from groups only to find that they required ‘View Member’ privileges for each group.
The official line is that although you don't need to be the owner of the class group, but you do need to be a member of the group and have access to the membership list to use it to invite students. Staff didn't really want to be members of the group (they get enough email) but they needed “view membership’ rights.
The issued can be fixed by manipulating the groups rights from within the console but this had two problems.
The first was the extra overhead required for 200 groups, the school really wanted a seamless solution and the second was the fact that since the group was managed through AD and GADS any change risked being overwritten by the next sync.
Nominating the teacher in the in the “Owner” field in GCDS solved the issue but many of the classes had multiple teachers so each sync needed to update multiple owners for each group and not just one.
As it turns out the owner field in GCDS can operate with multiple accounts.
If GCDS uses the ‘Owner Literal Value” and that value is pointed at an AD attribute that is ‘multi-value’, it happy manages multiple managers for the group.
For testing purposes we used the attribute wbmPath and populated it with email addresses of the teachers of that class.
GCDS then updated each account for that group - to everyone's surprise.
The school already has a mechanism to populate AD from the MIS system so this procedure was extended to write the teacher email accounts into the wmbPath field to create a self maintaining solution.
Heads up to Leon Cripps for chasing down and testing out this solution.
This might be well known fact but I can't find it documented anywhere and I think it might be useful to others.
The plan was to use GCDS to import AD groups that defined the class sets to be used with Classroom. The import created about 200+ groups across all years and subject areas and staff members were keen to start creating classes based on the group membership.
The problem arose when staff attempted to invite class members from groups only to find that they required ‘View Member’ privileges for each group.
The official line is that although you don't need to be the owner of the class group, but you do need to be a member of the group and have access to the membership list to use it to invite students. Staff didn't really want to be members of the group (they get enough email) but they needed “view membership’ rights.
The issued can be fixed by manipulating the groups rights from within the console but this had two problems.
The first was the extra overhead required for 200 groups, the school really wanted a seamless solution and the second was the fact that since the group was managed through AD and GADS any change risked being overwritten by the next sync.
Nominating the teacher in the in the “Owner” field in GCDS solved the issue but many of the classes had multiple teachers so each sync needed to update multiple owners for each group and not just one.
As it turns out the owner field in GCDS can operate with multiple accounts.
If GCDS uses the ‘Owner Literal Value” and that value is pointed at an AD attribute that is ‘multi-value’, it happy manages multiple managers for the group.
For testing purposes we used the attribute wbmPath and populated it with email addresses of the teachers of that class.
GCDS then updated each account for that group - to everyone's surprise.
The school already has a mechanism to populate AD from the MIS system so this procedure was extended to write the teacher email accounts into the wmbPath field to create a self maintaining solution.
Heads up to Leon Cripps for chasing down and testing out this solution.
No comments:
New comments are not allowed.