G Suite - Gmail for Students

[quaium]

We would like to give students access to Gmail, however, some staff are worried that Students will send emails to the distribution groups (i.e. All_Teachers, All_Staff), is there a way of hiding these email groups so that it will not appear in the students Global Directory but will still appear for everyone else?

[FN-GM]

No you can't hide groups (oddly). However you can sue compliance rules so if they send to a group the message will bounce.

[Primus]

You can both hide the group from the directory and apply a routing policy to prevent students emailing them at all.

 

Show/hide in the directory

 

Prevent students emailing certain groups

[quaium]

You can both hide the group from the directory and apply a routing policy to prevent students emailing them at all.

 

Show/hide in the directory

 

Prevent students emailing certain groups

 

Hiding the Group via this method would hide it from the entire organisation, am I right in saying that? If so, that's not what we want, we still want staff to see the Group.

[Primus]

Try this

[jthompson]

You can both hide the group from the directory and apply a routing policy to prevent students emailing them at all.

 

Show/hide in the directory

 

Prevent students emailing certain groups

 

We also use compliance rules to achieve this, but have done them slightly differently to that guide in that we've created them at the root organisation level, and then disabled the rule for the staff organisation (along with any other orgs that will need to send to the affected groups). The compliance rules are then effectively on by default, which is a little safer to manage long term.

[rogerdnixon]

You can also set the Groups permissions to restrict who can post and what they can do. Group permissions are very granular and can be configured in a number of ways. We tend to use group permissions rather than compliance rules for this reason (although we do use these in specific situations).

So we have a students group that contains all the students in the school. They are all members - but can only view messages and that's it. Various members of staff are either owners or managers and can post - but posting is restricted to managers and owners.

[jthompson]

The problem I have with Google Groups is that the permissions aren't granular enough. The scope for posting permissions is either the members or everyone. If you only want a subset of non-members to post, so have to open it up to everybody and then control delivery using compliance rules.

[DGardiner]

Hiding the Group via this method would hide it from the entire organisation, am I right in saying that? If so, that's not what we want, we still want staff to see the Group.

 

ive ended up using gam to automate my group memberships so they dont need to be listed in the directory and unlisted every group as were about to start onboaring pupils too..

[quaium]

Try this

 

This works well but hides all the users from the directory if no groups are added, it's a shame you can't add users individually. But hey, I guess showing nothing is better. I will also try out some of the other methods, thanks everyone!

[rogerdnixon]

The problem I have with Google Groups is that the permissions aren't granular enough. The scope for posting permissions is either the members or everyone. If you only want a subset of non-members to post, so have to open it up to everybody and then control delivery using compliance rules.

 

You can have anyone, organisation members, members, managers and owners - so there are five levels. So you can allow managers to post and not members for example. You need to click on view in groups services in the admin console to view all the settings. You can also do it via commandline using GAM.

[jthompson]

True. We use GCDS to sync groups, which doesn't give too much control beyond syncing members, owners and the name. I therefore found it simpler to have vanilla memberships, open posting up to the whole domain and then use compliance rules to reject messages from students. Same thing for our student groups.

All our staff groups have an alias that begins staff. (so staff.chemistry, etc.) which means that one compliance rule can cover all the staff groups without us ever having to go back and update it.

[peej2k]

Use quaium's link to create custom address books, and then set your mailing groups to only allow members to be able to send to the group.

[Ditto]

You can also set the Groups permissions to restrict who can post and what they can do. Group permissions are very granular and can be configured in a number of ways. We tend to use group permissions rather than compliance rules for this reason (although we do use these in specific situations).So we have a students group that contains all the students in the school. They are all members - but can only view messages and that's it. Various members of staff are either owners or managers and can post - but posting is restricted to managers and owners.

We're the same as @rogerdnixon to control who can post what to where. I haven't really looked in to the global directory or custom address books but it is something that I would like to one day. The persistent annoyance we see, is when staff email an address (e.g. days '[email protected]', it still showing the name of a predecessor - in my case, when some people email me, for them it shows the name of someone that I replaced nearly 4 years ago!

[jthompson]

We're the same as @rogerdnixon to control who can post what to where. I haven't really looked in to the global directory or custom address books but it is something that I would like to one day. The persistent annoyance we see, is when staff email an address (e.g. days '[email protected]', it still showing the name of a predecessor - in my case, when some people email me, for them it shows the name of someone that I replaced nearly 4 years ago!

 

Could that be a result of what the sender's account has accumulated in their suggested contacts (i.e. prior correspondence)? Should be easy enough to test, but a different matter to fix it.