Some details on Office 365 Groups

Some basics on Office 365 Groups architecture

As you may already know, there is many types of groups available in Azure AD to create permission roles and shared mailboxes and combines application objects like Office 365 Groups.
Office 365 Groups is intended to serve as an application-centric object, that coveres some commonly used apps together in a single workgroup space, based on different communication scenarios.

It’s based on two permission levels originally, Owner and Member, and intended to be managed as a self-service by a typical user in your organisation, who does not hold any special roles or permissions.

Another typical thing about the app objects contained in an Office 365 Group is that it is designed as a flat object. The meaning of “flat” is, that it is not designed to contain containers for other hierarchical input objects. Some examples to proof that is like this: a project manager is a lead for some employees as the members of the project team, working at the same stuff/resources. So you manage members and resources very close to the role that uses them.

As employees and other team members are also known as users, you can only add user objects as a member or additional owner to a team. You cannot add groups as an owner, and you also cannot nest Office 365 Groups permissions using security groups which could have been synchronized from your on-prem environment directly. You must use an direct assignment.

The same is for the apps for an Office 365 Group. They are also designed to be flat. A shared mailbox content based on an Office 365 Group has exactly 1 folder level only (shown as the name of the group in the “Groups” section of your folder list-pane), but you cannot create subfolders. No folder hierarchy, no tree design where a user can move your mails to the 100th sub-level in her folders tree. It’s just an easy to handle place to collaborate on e-mails. Yes, you still can create some folder hierarchy within the Sharepoint Document library.

As I’m currently preparing for the Office 365 Deverloper Bootcamp, I wonder why so many of my friends at the community seem to be unaware with the base concept of Office 365 Groups.

Different types of Office 365 Groups

There is three different types of Office 365 Groups, that you may choose from

Outlook groups; this type contains
- a shared inbox for e-mail communication. You can send mail to the Office 365 Groups e-mail address and forward incomung mail to group members. No subfolders can be created.
- shared calendar. Schedule your work groups meetings and appointments here.
- a Microsoft Planner to assign and manage your tasks within your workgroup
- a shared OneNote Notebook to store your project documents, meeting minutes and other notes.
- a Sharepoint Document library. Store your files here.
- a Sharepoint Team site

Please be aware that you cannot manage the unterlying Sharepoint Team site on tenant-admin.sharepoint,com; add this to your considerations when it comes to questions about backup and deleted items retention. Ask an expert rather than throwing in the towel. While saying that: yes, you can still see the sites when choosing PowerShell.

Yammer groups
- a Yammer Group; ok, this is pretty obvious. In a yammer group type the yammer group is the intended object to use as the related communication. Please be aware that you checked the when-to-use-what big picture created by Avanade or you really read some of the intended target audience documents on MSFT docs.
- Planner, once again this is used to manage your tasks. Be aware that while you could manage some schedule when using an Outlook group type, these tasks are based on due dates and (open, WIP, done) status attributes
- shared OneNote Notebook – same as for the other group type
- SharePoint Team Site – same as for the other group type
- SharePoint Document Library – same as for the other group type

In my own world, I didn’t find a customer who had chosen to use Yammer groups yet.

Ah, and finally there is another type when you choose to use Microsoft Teams.

Microsoft Teams and Office 365 Groups

While the other group types are well-defined in the Office 365 Groups article at MSFT docs, I didn’t find an article with an explicit statement about what can be included in a Microsoft Teams group type. My current knowledge is based on the article “Office 365 Groups and Microsoft Teams”.

a Sharepoint Team site – the article explains, that still receive a Sharepoint Team site where your team lives in, including folders for your Teams channels and using the included Document library for your Files tab. In addition, if you create your custom folder structure within the Document library it does not create that in the Teams group to prevent you from creating channels that way. Instead it links your folder to the Sharepoint site, only.
an Inbox folder – there is an article “Send an email to a channel in Teams” at Microsoft Support, which explains how to receive an incoming mail at your conversations tab in Microsoft Teams. This feature needs to be enabled by your IT admin. You can find the required settings at the Microsoft Admin Center under Sevices & Addins, Microsoft Teams, tenant-wide settings, E-Mail Integration.
(Be aware that it may be moved to an updated version of the Microsoft Teams Admin Center in future!)

As you can read from the above, there is some Sharepoint Team site created. I found users out there which associate that sites to a Sharepoint Hub site. In my eyes, this is really a bad idea, as a workgroup typically lives only for a small amount of time. You may end up in many broken links on your hub site. Don’t use unmanaged sites for managed site tools.

While working with the Microsoft Teams app is really easy and you speed-up your workgroups interaction by using
Microsoft Teams, please be aware that espacially those who did not move to use Outlook group types in the past get familiar with the architecture of Microsoft Teams group types first at your IT teams. Working in Teams is really easy for you as an user as well as an IT Ops guy, but you must get familiar with the apps around your Microsoft Teams group types. Only that will prevent you from going to the beastiary hell of non-compliant Microsoft Teams implementation.

Naming policies, prefix, postfix and restrictions

To meet your IT governance requirements, you should really take care for your cloud naming policies and concepts around that for the different tools you can get. It’s the same for Office 365 Groups. It’s good to know there is an article “Office 365 Groups naming policy” out there at support.microsoft.com which tells you exactly about what is possible and what’s not. Let’s review the article and repeat some key facts

You can have this as your naming policy for an Office 365 Group

Prefix-Suffix naming policy
custom blocked words

Prefix-Suffix naming policies can be build on a string pattern including the token [Groupname] (let’s call this the name attribute for now) for a group name, custom strings for fixed values that may be concated before or after the name attribute, like [department]. Obviously you cannot use calculated values based on the Group name the creator entered. And please remember

you will not exceed the 256 characters limit for a security group.
the total prefixes and suffixes string length cannot exceed 53 characters
Policies will not work for Global Administartors, User account administrators, Directory writers; it’s intended to keep your users within the policy
If you use delegated administration with your Microsoft Partner, it will not be applied to Groups created by an Partner Tier 1 or 2 Support member

One more word on attributes – attributes currently available are limited to [Department], [Company], [Office], [StateOrProvince], [CountryOrRegion], [Title]. customAttributes, extensionAttrbutes as well as other user attributes are not supported at the time of writing this article.

“Group naming policy requires Azure Active Directory Premium P1 license”, so check your licensing before you go and try it.

Remember, that group naming policy and word block lists is currently still in preview (I personally think it’s good enough to use it in production). As you cannot manage that policy by the Microsoft Admin Center GUI on the web, you need to use PowerShell or Microsoft Graph; the feature can be configured in AzureAD, but you must use the module AzureADPreview for now, as the AzureAD module currently does not include the Microsoft Graph components.

And of course, settings a naming policy to a group also restricts your Teams names, so you can filter easily for them in your AzureAD groups

Create Office 365 Groups permissions policy

When creating a new Office 365 tenant, by default your users are permitted to create their custom Office 365 Groups. While I personally think this is a good practice your speed-up users to work in a shared environment, some Companies who require strict governance on permissions to apps may not like that approach. Luckily, you are able to prevent non-admin users from creating Office 365 Groups. At MSFT Support there is an article available to “manage who can create Office 365 Groups”. Basically, you need to configure the attributes “EnableGroupCreation” (set it to false) and put some permittedUsersGroup ID to the “GroupCreationAIIowedGroupId” to restrict that.

other policy options you might want to review…

There is some more policies to configure Azure AD behaviour and manage Office 365 Groups, like AIlowGuestsToAccessGroups, GroupCreationAIIowedGroupId, AllowGueststoBeGroupOwner, AllowGueststoAccessGroups, AllowToAddGuests. Please review your AzureADDirectoryTemplates for the Group.Unified* Objects; you can review all objects by PowerShell using AzureADPreview.

Manage AAD Connect and sync your membership with Office 365 Groups

The MSFT docs article “Configure Office 365 Groups with on-premises Exchange hybrid” describes how you can manage Office 365 Groups from our on-premises Exchange environment. To do that, you need to use the group writeback feature in Azure AD. So the membership depends on your AD DS schema, which requires a current Exchange Server schema extension to use this feature.

Please be aware that your require Azure AD premium to use groups writeback for Exchange, and you may check the license terms for the on-prem Exchange Server software as well before you extend your schema.

After subscription, just go to your AAD Connect instance and enable the Groups Writeback option in optional features.

final words?

I hope you find this article useful when thinking about Office 365 Groups. Go and check the original articles by microsoft mentioned above. If you need some step-by-step guidance, let me know – but as this article is intened to work as a global overview for Office 365 Groups, this is a task for a different post..