Many Great Views About How Microsoft 365 Groups Work
We received a great response to our Microsoft wants to talk about Group Sprawl (Finally) post. In the post, I recommended that tenant administrators take up Microsoft’s invitation to talk about their experiences of managing Microsoft 365 groups. Today, I spoke to the team driving this initiative and heard that they had many interviews lined up with people who responded to the post. That’s real community feedback in action.
If you haven’t yet signed up and have some opinions about what Microsoft should do to improve the manageability of groups, I encourage you to take the opportunity to express your views. Office 365 is a huge market, and the needs of administrators in a 5,000-seat tenant are very different to those who run mega-tenants. Everyone’s got insight into how well groups serve apps like Teams, how the management tools work (and don’t), and perhaps some requests to make. This is a chance to affect Microsoft’s roadmap and it’s important that Microsoft hears from as wide a variety of tenants as possible.
I took my chance to express my opinions when I had an hour-long chat with the Groups developers today. I don’t expect everyone to agree with my views but thought it worthwhile to document them here so that people have a chance to think about the kind of discussions which are ongoing.
Help Tenants Restrict Group Creation
First, I asked for the ability for every user to create new groups become an opt-in choice rather than the default. Aligned with this, I think that Microsoft should include the ability to restrict group creation to a nominated set of users and the group naming policy in Office 365 E3. Both features require Azure AD Premium P1 today and the licensing requirement is a barrier for exerting control over group creation, especially in SME organizations (who might not subscribe to the EMS suite and gain Azure AD Premium licenses through that route). Of course, the definition of what an SME organization is varies from country to country.
I know some have strong feelings about the goodness of allowing users to collaborate as they wish. I feel that these feelings are based on some weak foundations because the experience of years is that not everyone will behave as well as they should when given the ability to manage resources. If an organization wants to allow free rein, then they can opt-it. Otherwise, an organization can control group creation at their pace.
Deliver Integrated Group Management Across All Apps
Second, I asked for a consistent management platform for groups. Today, management is scattered across the Microsoft 365 admin center, SharePoint Online admin center, Exchange Online admin center, Azure AD portal, and the Teams admin center. It would be nice to have a single portal for groups management to control all settings applicable to groups and the source for analytics and reports about groups.
Provide a Simple Approval App for Group Creation
Third, I thought Microsoft should create a simple approval workflow for group creation. If an organization chose to limit group creation, users should be able to make a request from OWA, Outlook, Teams, or SharePoint and have a nominated person review and approve (or reject) the request. If OK’d, the group is then created. It should be possible to build an app like the Teams Approvals app (based on Dataverse) to work everywhere.
There are many examples where people use Power Automate to build an approval process for group creation. A Microsoft version should be simple and straightforward with the aim of satisfying the needs of 80% of organizations. Those who need something more complex can continue to use Power Automate or invest in an ISV solution, like Quest On-Demand Group Management. The intention is not to take business away from ISVs. Instead, they will continue to focus on the needs of large enterprises or other businesses which need specific workflow. The rest of us can live with a simple approval app to say yes or no to requests to create new groups.
Clean up Group Debris
Fourth, I pointed to the group debris cluttering tenants today. This debris is composed of obsolete, unused groups. You can make the point that it doesn’t matter if unused groups exist in a tenant. After all, no one pays for these groups. But the clutter slows down administrative interfaces and makes it harder to interact with useful groups. An adage of email in the on-premises world was that you could expect organizations to create more distribution lists than mailboxes (at one point, Microsoft had more than 400,000 distribution lists). This happens with groups today, and the profusion of groups makes administrative actions harder and slower.
Take the Groups section of the Microsoft 365 admin center. It lists groups alphabetically, and while you can search for a group (but only by name), browsing through endless pages of groups is painful, especially when the unwanted groups obscure the valuable groups. Of course, you could prefix especially valuable groups with “a” to make sure that they appear first in the list, but that’s a nonsense. Take another example of running PowerShell or Graph queries to process sets of groups. Each piece of debris increases the time needed for a query, as anyone who has ever run the Get-UnifiedGroup or Get-Team cmdlets can attest. And if you get to the point where maybe half your groups are debris and the tenant supports thousands of groups, that’s hours of administrator time waiting for PowerShell or the Graph to respond.
My solution is that Microsoft should include the Groups Expiration Policy in Office 365 E3 and above plans and encourage tenants to use the policy to remove unused groups after a suitable period. The current version of the expiration policy works off a limited set of signals to figure out if a group is active. That process needs to improve because it doesn’t value every activity in a group, but it’s still better than nothing.
Exploit Sensitivity Labels
Last, I recommended that Microsoft make more use of the container management functionality in sensitivity labels to allow easy policy-based control over group settings. Apparently, SME organizations make more use of sensitivity labels for container management today than their enterprise counterparts do. This surprised me, but it might just reflect the pace of change that IT sometimes follows inside large organizations.
You can’t cover everything in an hour. If you do sign up to talk to Microsoft, spend some time preparing a list of what you want to discuss, and then reduce it to a small number of high-priority items. I had five. You might have four or six. Enjoy the chat!
It would be easy to write a script to report groups that are coming up to their expiration date. But I take your point and agree that Microsoft has room to deliver better management tools in this space. Whether adaptive retention policies are the answer remains to be seen. We’ll make that decision after we see them in action.
Beside simplifying process of group creation approval, what I totally agree is needed we are still struggling with O365 groups clean-ups and lifecycle management.
Currently, there is no way to say which groups will exactly be in scope of expiration lifecycle management before you apply it. There is a script that Tony provided for activity usage (best we can get right now), but it’s still not something that is saying for sure which O365 groups are obsolete and ready for deletion.
Also, once group expiration is enabled we are able to pull-out expiration attribute (expirationDateTime) from GraphAPI only. Together with a consistent management platform for groups it would be good to have an easier method there to see the activity and group expiration date time.
Something that is currently in development are adaptive retention policies, and I’m happy to see it as it will help us a lot in groups expiration management vs. retention policy. In enterprise organizations we have a different regulative requirements to preserve data from the O365 groups even they hit the end of expiration lifecycle. As we can’t afford to have only O365 groups retention policy with include/exclude options there, scoping policies on O365 groups via department or country attributes will help a lot there!