Usually, a Microsoft 365 group can be created by anyone in your organization as part of creating a Team, a Yammer community, an Outlook group, a SharePoint site, etc. If the group owner leaves the company and the account gets deleted, the group becomes ownerless.

It would be a nightmare to reach out to ownerless group members one by one, trying to figure out who is the actual data owner and who should become the group owner. So we need some kind of automated solution.

There is a Microsoft ownerless groups policy that detects ownerless groups and sends emails to the most active group members, asking if they want to become group owners. If a member accepts ownership, the policy automatically elevates that person from group member to group owner. The policy does not cover standalone SharePoint sites, but the majority of orphaned resources in an organization are usually Microsoft 365 groups, so this policy should still help a lot.

The policy was designed with the idea of preventing ownerless groups, meaning it handles them gradually over time as they become ownerless. Because of that, it’s recommended to activate the policy as soon as you set up the tenant. Configuration is done through the GUI, and it’s intuitive and straightforward. Microsoft documented it well, but if you still have questions about how the policy behaves, here is my Q&A covering what is not included in Microsoft’s FAQ, along with some tips, tricks, and gotchas.

The problem is that Microsoft introduced this feature relatively recently, and if you’ve owned your tenant for years, you probably already have some ownerless groups. In small or medium environments with a few dozen ownerless groups, this isn’t a big issue. But in a large Microsoft 365 or SharePoint Online environment, you might end up with hundreds or even thousands of ownerless (or orphaned) resources that you have to deal with.

One of the challenges is how to implement the policy correctly when you already have many ownerless groups, and then how to manage the groups that will become ownerless in the future. In other words, we need to solve 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 that we have strict requirements we need to satisfy:

• end-users to get a limited number of emails in a certain period so they can process
• 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 piloted or tested in production against a small group 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 the 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 cannot reconfigure the policy or reactivate it to trigger additional messages for groups that already had messages generated earlier. In other words, if email notifications were already sent for a group and the policy stopped working after the defined time period, it’s done for good. No more emails can be generated for that same group.

The other limit is you can only specify no more than 50 Microsoft 365 groups in policy under “Apply policy to Specific groups” option. And we’d keep in mind exchange’s limit of 10,000 emals per account 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 (100+ members): <1%, i.e. 10-20 groups
• medium m365 groups (10-100 members): ~25%, i.e. ~1000-2000 groups
• small m365 groups (1-10 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:
  skip the policy, use PowerShell to 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:

Wave 0 – piloting

select a few (3-5) ownerless m365 groups, preferably your colleagues from IT – whose members will be your pilot team, so you could finalize all settings and polish notification message etc.

Implement the policy with settings:
– All active members, 5 members to notify, 2 weeks
– Sender
– Subject and message – clean-up oriented
– Specified groups – select these pilot groups

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 etc.

Wave 1 – large groups and small groups

Implement the policy for large with settings:
– All active members, 5 members to notify, 5 weeks
– Sender – specially created m365 group with the name you need as sender
– Subject and message (polished at wave 0, clean-up oriented)
– Specified groups – select large groups

For small groups – run PowerShell script that elevates members to owners.

Wave 2 – medium groups and null groups

For null groups – run PowerShell script that removes groups with no owners and no members (optionally only inactive groups and/or no content groups).

At this moment number of ownerless groups should be decreased significantly. So we should be good to start implementing policy for all groups. But we are getting new ownerless groups permanently – during all the waves of policy implementation.

Get the report again. In case you have e.g. up to 2,000 orphan groups – you can reconfigure policy and “Apply this policy to” All groups.

If you have more than 2k ownerless groups left – consider the following: create a few service accounts in Entra ID. Add these account to ownerless groups as owners (distribute equally). That’d make groups not ownerless. Then you’d configure the policy. Than delete these service accounts from entra id one by one, so it’d make groups ownerless again, but not all at once, but gradually.

Wave 3 – all groups left ownerless

After a few months you configured ownerless groups policy for all groups – get reports on your orphan groups again – there should be some % of remediated groups, and some % of groups that are still ownerless after all notifications sent to most active members (nobody volunteered to be a group owner). But you still need to deal with these ownerless groups. Consider the following approach based on groups activity (this would require PowerShell):

• active groups – elevate most active members to owners
• groups with no recent activities – rename group, remove all members, configure “request access” email and let the group stay for a few more months/years – then delete groups not reclaimed

Wave 4 – permanent policy and custom deletion

After you completed clean-up (policy + your custom solution), consider policy re-configuration.
Specifically, you might want to update the notification Subject and Message.

Questions 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 owner – 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 does not get access to private channels automatically
c) shared channels stays with the same permissions also

References

• Ownerless m365 groups Q&As, gotchas, findings…
• Microsoft’s “Microsoft 365 ownerless group policy FAQ“
• Dealing with Ownerless Groups in large Microsoft 365 environments