Usually Microsoft 365 group can be created by anyone in your org as part of creation a team, Yammer community, Outlook group, SharePoint site etc. If the group owner lefts the company and account got deleted – the group became ownerless.
It would be a nightmare if we’d reach ownerless groups members peron-to-person trying to find out who is a real data owner and who should be a group owner. So we need some kind of automated way.
There is a Microsoft’s ownerless groups policy that detects ownerless groups and sends emails the most active groups members with the question- if they want to become a group owners and in case member accept ownership – policy automatically elevates a person from a group member to group owner. Policy does not cover standalone sites, but majority of orphaned resources in org are usually m365 groups, so that policy should help.
The policy was designed to prevent ownerless groups concept in mind, i.e. to deal with ownerless groups gradually – stretched in time – when they become ownerless. So it is actually recommended to activate the policy once you get the tenant right away. Configuration is done via GUI, it is intuitive and straightforward. Microsoft documented it well, but if you still have questions regarding the policy behavior – here is my Q&A on what is not covered by Microsoft’s FAQ as well as some tips and tricks and gotchas…
The problem is that Microsoft introduced this feature just recently, and if you own the tenant for years, you probably already have some ownerless groups. In small and medium environments with a few dozens of ownerless groups it’s not a big issue, but in a large Microsoft 365 SharePoint Online environment you might end up having hundreds and thousands of ownerless (orphaned) resources you have to deal with.
The challenge is how to implement the policy correctly if there are already many ownerless groups present and then to take care of groups that will become ownerless in the future. Yes, we’d need to address two consecutive issues:
- Remediate vast amount of existing ownerless groups
- Prevent groups to become ownerless
Obviously we’d need two different strategies and policies configurations.
There are also 3-rd party tools – like SysKit Point that can help with orphaned resources by enforcing minimum number of owners. There is also “Orphaned resources” policy under SysKit that allows multiple workflow options to resolve the issue – but there is no “fully automated” option -all SysKit options require an interaction from admin/manager.
Microsoft 365 built-in feature – “Ownerless groups policy” allows fully automated process:
- detects ownerless groups, and for every group found
- generate e-mail invitations to most active group members
- assigns users as group owners if they accept invitation
Another problem in large environments is we have strict requirements we want to satisfy:
- end-users to get only a few emails in a certain period so they can process it
- end-users get only relevant messages so they will not ignore further notifications
- high percentage of acceptance and (ideally) no orphaned resources
We want the policy to be tested in production but within a small group first and then we want phased implementation – so we could have a chance to get a feedback on phase 1 and adjust our approach at phase 2 etc.
The policy allows limiting policy scope in two ways:
- by limiting “who can receive” messages – it’s done by specifying a security group – so only this security group members will be eligible to get invitation and accept or decline it
- by limiting Microsoft 365 groups that would be in scope for the policy – it’s done by specifying group names
Two options can be specified in the same policy and effective eligible members would be those who satisfy both requirements.
Configuration is done using GUI – i.e. there is no PowerShell commands known on the subject at the moment.
There are a lot of “what if” questions regarding the policy – most of them are resolved in Microsoft’s “Microsoft 365 ownerless group policy FAQ” and my Ownerless m365 groups Q&As, gotchas, findings…
But the most important gotcha for me is that we do not have a chance to re-configure the policy or re-activate it to get more messages for the groups all messages were generated earlier. I.e. if an e-mail messages were generated for a group and the policy stopped working after a specified period of time – it’d done forever. No more e-mails could be generated for the same group.
The other limit is you can specify maximum 50 m365 groups in policy under Apply policy to Specific groups option. And we’d keep in mind exchange’s limit of 10k emals per day.
So, having this said, what would be the proper approach to do phased implementation in terms of configuring policy to scope it down for each step?
First – know your data. Get full report on ownerless groups, analyze it and come up with approach. Let’s assume we have an org with ~100K users and ~5000 ownerless groups. I bet you will find out that you have
- large m365 groups (50+ members): <1%, i.e. 10-20 groups
- medium m365 groups (5-50 members): ~25%, i.e. ~1000-2000 groups
- small m365 groups (1-5 members): ~50%, i.e. ~2500 groups
- null m365 groups (0 members): ~25%, i.e. ~1000-2000 groups
You’d might have your own classification, but I would propose the following approach to each category.
- large groups:
configure policy with “Apply policy to Specific groups” option
and specify all or several of your large groups (the limit if 50 allowed groups in this field) - medium groups:
configure policy not scoped down (e.g. apply to all groups, all users) - small groups:
elevate all group members to owners
optionally – elevate specific titles (manager, lead) or salary grade members to owners - null groups:
consider deleting these groups
optionally – delete only inactive no-members groups or groups with no or small amount of storage/files.
You’d also come up with the ideas on
- desired min and max number of owners
- deleting groups/sites phased approach
- archiving groups/teams/sites
Remember – this is production, so at this moment you should test the policy in non-prod an be fully comfortable with all aspects of configuring the policy and formatting e-mail template etc.
As a remediation part plan I would propose the following:
(WIP)
Wave 0 – piloting
select a few (3-5) ownerless m365 groups came from IT – whose members are your pilot team members, so you could finalize all settings and polish notification message etc.
Implement the policy with settings:
In parallel, while you are waiting weeks for the policy to pause, start developing PowerShell scripts that will 1) delete null (no members) groups and 2) elevate members to owners (get how many members can be elevated if elevate only certain members)
Track user’s response – % of declines and accepts
Get feedback from users – how well the notification message is understandable
Wave 1 – large groups and small groups
Implement the policy with settings:
In parallel, you should already know – how many members can be elevated if elevate only certain members, decide on that and and run PowerShell script that elevates members to owners.
Wave 2 – medium groups and null groups
Implement the policy with settings:
In parallel, run PowerShell script removes groups with no owners and no members (optionally inactive and/or no content).
Wave 3 – all groups left ownerless
Implement the policy with settings:
Wave 4 – permanent policy and deletion script
Implement the policy with settings:
two more moments to consider:
– After all the measures against ownerless groups is done, we will probably still have some groups ownerless
– We will be getting new ownerless groups permanently – during all the waves of policy implementation
Qestions and Answers
Q: Isn’t it a security risk if we elevate members to owners? Would a member get access to more information that he/she did have access to before.
A: 1) Elevating members is the same risk as implementing the ownerless policy, as policy does the same – it elevates member to group owner.
2) When a member is elevated to group owners – a member does not get access to more information, as
a) for standard channels – he/she did have access as a member
b) private channels stays private – new group owner dos not get access to private channels automatically
c) shared channels stays with the same permissions also
TBC
