Microsoft is redefining what collaboration means with Office 365 Groups.
If you don't know, Office 365 Groups is a service that enables teams to come together by establishing a single team identity and a single set of permissions across Office 365 apps including Outlook, SharePoint, OneNote, Skype for Business and Power BI.
In this post, I am going to share some lessons that I learned while helping clients roll out Office 365 Groups, and apply settings to govern it.
You can have all, none or some of your end-users create Office 365 Groups. You must decide what permission levels are best for your organization and your end-users.
Full End-User Access (All)
Giving all end-users access means anyone is free to create Groups. This is the most democratic option, but can have negative implications. You run the risk of having a directory with a lot groups. Not to mention, some that go unused or that are overlapping.
Admin-Only Access (None)
You can restrict end-users from having the ability to create Groups and keep that power in the hands of Admins. You get much more control with Admin-only access. However, you may want to implement a system or form form which end-users can request a Group be created.
Specific Access (Some)
You can restrict creation of Groups to a group of specific users. This gives you control over the people creating Groups, while still letting some end-users have access. I've found this can help increase user adoption.
In order to have good data governance, you need to associate data classifications with each Office 365 Group. Ex: Internal Use, Need to Know, Privacy Data,Trade Secret, etc. A well-planned data classification system makes data easy to find and govern.
Note: Currently, settings around data classifications are free form text. These settings can also only be applied after a group is created - there is no way to apply a data classification while creating the group.
You must determine how to handle guest users by determing if you want or don't want them to have access to Office 365 Groups. You'll need to decide whether or not to allow Group Owners to add guest users to groups. Note: If you restrict access after a guest has alreaft accessed your Groups, the settings change will not stop their access.
Simply put, this is a 'yes' or 'no' question. Your organization may already have guidelines established on how to govern guest users. Most organizations I work with prefer to exclude guest user access to their Office 365 services, and seek out other collaboration methods.
To help the individuals creating Office 365 Groups, you can provide usage guidelines. These guidelines should be a one page document that inform your Group Owners about usage and guest access.
These guidelines will pop up as an HTTP link in the UI while an individual is creating a group. The guidelines can be hosted in central location like a policy portal or intranet. Don't forget! You will need to make sure the link you set up is accessible by users creating groups.
A naming policy can be defined with a prefix or a suffix to append to the free-form group names, and to further standardize/define the Office 365 Groups that were created. You have an option to use either free-form text or AD attributes to use as as part of naming policy.
Ex: If you have defined “GRP-” as a prefix, a “-” as suffix and another suffix as AD attribute “Department”, If a user creates a Group, a Group name will be formed in a way to use the free-form text and users AD attribute value as suffix.
“GRP-Project XYZ-Finance” or “GRP-Project XYZ-IT”
You can append multiple prefixes and suffixes in your naming policy. Naming policies are a good way to make sure Groups stand out in your directory. There are couple gotchas to keep on eye on while forming the policy.
- If you opt-in to use AD attributes, Group Owner’s AD attributes will be used to construct the name of the Group. In a case when another user creates Group for another user, there might be mismatches.
- Prefix and suffixes will be added to the SMTP address for Office 365 Group mailbox. e.g. firstname.lastname@example.org email@example.com
Note: Currently, naming policy can ONLY be applied via Exchange Admin Center, and can ONLY be enforced for Office 365 Groups created via Outlook. Any group created by another service such as SharePoint, Planner or else, will not respect this naming policy. This will change when Microsoft rolls out the feature to define naming policies in AAD level and enforce it across all services. You can see this item in development in the Office 365 Roadmap.
How do I apply all of these settings?
It's easy! Besides the naming policy, all of the decision can be applied as a setting using Azure AD PowerShell.
Prerequisites: Make sure you installed Azure AD module for PowerShell version 126.96.36.199 or later
To learn more about Office 365, Microsoft's platform for productivity & collaboration, reach out to a member of the Blue Chip team!