Tag Archives: Ownerless groups policy

SharePoint Governance

SharePoint Governance: list of articles

References

Dealing with Ownerless Groups in large Microsoft 365 environments

Microsoft 365 groups is a key concept in today’s collaboration landscape that includes Microsoft Teams, Viva Engage, SharePoint etc. Access to resources is organized via groups. It is essential that every Microsoft 365 group has an owner (owners) so we have somebody to enforce Collaboration governance through.

Scenario

Let say you administer a large Microsoft 365 environment (e.g. ~100k+ users and/or ~50K+ sites) and after some years you have a lot of ownerless groups and sites (around 5k probably), and a lot of inactive groups and sites (maybe 15k). You are getting more and more ownerless groups – dozens each week. You are thinking of stopping bleeding and cleaning this up…

Out-of-the-box we have Microsoft 365 groups expiration policy and Microsoft 365 ownerless groups policy. You might also have some 3-rd party tools implemented – e.g. ShareGate, SysKit Point.

If you do not care – you might just activate both OotB Microsoft policies – via GUI – they are simple to activate. But once you activated policies – they will trigger thousands of emails. Now imagine a person is getting dozens of emails asking him/her to be an owner or to renew the group that probably he/she has no idea about… What will happen next? People will probably ignore these alerts. Then? Groups and sites will be automatically deleted. And then? Right, there will be a huge noise and many angry users and high-priority tickets and you will have to restore sites/teams and finally you’ll have to deal with all that mess manually.

So, what is the right way to clean-up a large Microsoft 365 environment from ownerless and inactive teams, groups sites? Not a trivial question, hah?

Solution

Disclaimer: I’m sharing here my personal opinion with no obligations or warranty etc., so you’d dig into all the technologies used and based on your particular situation build your own plan. But my personal opinion is based on my 15+ years experience with SharePoint, including really large environments.

Note: It is always a good idea to discuss your plans with you org’s communication team and helpdesk/service-desk to adjust clean-up activities with other initiatives and let other people be prepared.

High-level steps for group-based Sites:

consider implementing Minimum 2 owners per group policy to stop bleeding. Currently Microsoft 365 does not have such functionality, so consider 3-rd party tool like SysKit Point or custom PowerShell script that sends notifications
- apply this policy to groups where you already have 2+ owners – it’ll be safe
- apply this policy to all other groups by chanks
consider custom PowerShell clean-up, e.g. you can simply delete groups with no owners and no members and/or inactive groups with no content and/or groups that are inactive for a long time (this must be aligned with business and legal)
implement Microsoft’s Ownerless groups policy in “Clean-Up” configuration; there are some tricks and gotchas worth a separate post, but in short
- avoid scoping down this policy via people (security groups)
- implement it for all groups all users with 6-7 weeks and custom e-mail template
implement Microsoft groups expiration policy in “Clean-Up” configuration… again, there are a few different strategies – see this article
change Microsoft Ownerless groups policy configuration to a “Permanent” mode configuration set
(or) change Microsoft 365 groups expiration policy with a “Permanent” mode configuration
(or) develop and implement custom staged decommissioning process – kind of “last chance” set of scripts to discontinue groups that are still ownerless after all efforts above. Staged means we do not just delete these groups, but e.g. we can
– rename ownerless groups
– convert groups from public to private
– set teams to archived mode
– exclude sites from copilot search with “Restricted SharePoint Search” etc.
– set site to no-access mode
– remove members from the group
– and finally delete the group with connected team team and site
I have a separate article on custom staged decommissioning process

Note: There will always be ownerless groups in large environment. We have to live with it. So all steps above – think of it as a processes – we’d need to do it on regular basis.

All above was mostly about group-based sites (as we have OotB Microsoft policies for groups), but we probably have the same problem (or even worth) with standalone sites (that would be a separate topic).

SharePoint Inactive Site Policies

Recently (2024-2025) Microsoft developed SharePoint Advanced Management set of features and offers it as an add-on to SharePoint (aka SharePoint premium). SAM includes Inactive Site Policies under Site lifecycle management. This policy can work not only against group-based sites, but against all sites, including standalone sites. The other big difference is that this SharePoint Inactive Site Policy do not delete sites, but allows to set site to read-only mode and archive. See SharePoint Inactive Site Policies deep dive.

Microsoft 365 admin center: Manage ownerless Microsoft 365 groups and teams

1 Reply

There is a new feature published at Microsoft roadmap site:

Microsoft 365 admin center: Manage ownerless Microsoft 365 groups and teams

Teams, Outlook groups, Team Sites etc. powered by Microsoft 365 Groups supports two roles: members and owners. Members can collaborate with others in the group through files, emails, messages etc. Owners manage the group membership and monitor content and conversations. When employees leave an organization or switch projects internally, it results in their existing user accounts getting deleted. If such employees were group owners, keeping track of their groups becomes critical to ensure accountability within the organization. We have introduced a new ownership governance policy to help automate the management of ownerless groups by requesting active members to become owners of the group. Admins can define who is eligible for these notifications and configure what notifications and how often these notifications are sent to active group members. Users, who are members of the ownerless groups can simply accept or decline request via the actionable email message.

Feature ID: 180749
Added to roadmap: 10/10/2023
Last modified: 10/10/2023
Product(s): Microsoft 365 Admin Center
Cloud instance(s): GCC
Platform(s): Web
Release phase(s): General Availability

But based on the feature description – all looks exactly as what we already have for years as “Microsoft 365 ownerless groups policy” which you can configure under Microsoft 365 Admin Center -> Settings -> Org settings -> Microsoft 365 groups

Massive Microsoft 365 groups update with PowerShell

1 Reply

What if you need to bulk update Microsoft 365 groups membership e.g. to add a group owner or member for tens of thousands m365 groups? Iterating through groups one-by-one is unproductive and could take days. Can we do it faster? Here is what I found.

In my case, it was Microsoft 365 ownerless groups policy implementation for large tenant… Skipping details – I needed to update ownership for 10,000 Microsoft 365 groups and I was looking for a best/fastest possible option maybe some kind of bulk update or with multiple threads. And I figured out that the fastest way is to use PnP.PowerShell that calls Microsoft Graph API but run it against list of groups with PowerShell parallel trick. Here is the sample PowerShell code:

$groups | ForEach-Object -Parallel {
    $owner = "newGroupOwnerUPN@contoso.com"
    Add-PnPMicrosoft365GroupOwner -Identity $_.Id -Users $owner
} -ThrottleLimit 50

That worked for me perfectly and it took ~8 seconds per 1,000 groups.

Ownerless groups and dependent channels

1 Reply

Here is the scenario:

There is a team (including SharePoint site) under Microsoft Teams. There are multiple channels under this team with types:
– standard channel
– shared channel
– private channel

A single group owner (team owner) leaves company and the team (group) becomes ownerless. Question: what will happen with private and shared channels?

A group (team) gets a new owner. Question: what will happen with private and shared channels?

“Microsoft Teams – Teams And Channels Service made you an owner of a channel”

TBP

Ownerless resources in Microsoft 365 SharePoint

3 Replies

I have multiple publications on the subject – how to manage ownerless groups in Microsoft 365:

New (June 2025): Microsoft released a new SharePoint “Site Ownership Policies” under SharePoint Advanced Management.
Ownerless Microsoft 365 groups deep dive (FAQ)
Implementing Microsoft 365 ownerless groups policy in large environment
Microsoft 365 ownerless group policy to send more than 10,000 notifications
Ownerless group policy configuration failed Failure in configuring ownerless groups policy Please try again
Manage Microsoft 365 groups membership with PowerShell and Graph API
Ownerless teams and channels – private and shared channels
m365 ownerless groups policy email message body format and content tricks
Feature ID: 180749 Microsoft 365 admin center: Manage ownerless Microsoft 365 groups and teams

And 9 videos :

Microsoft 365 Ownerless Groups Policy Deep Dive: Introductions
Policy Overview and Configuration
Customizing Policy Notification E-mail Template
How is the m365 Ownerless Groups Policy Looks Like for User
Scope the Policy Down for Piloting and Phased Implementation
Configuring Policy for Environment Cleanup
Configuring Policy for Permanent Use
Notification Period Ends, Members don’t Respond – What’s Next?
Reporting on Policy with M365 Audit Log
Closing notes Policy Tips and Tricks

Here is the Introduction video and content covered in next videos:

Ownerless group policy configuration failed

1 Reply

If you are seeing “Ownerless group policy configuration failed” and “Please try again.” error message:

there might be some different reasons:

Microsoft said it is (was) a know problem – it happens sometimes (timeout?), if you configured the policy properly and have enough permissions.
So just go back one step and try again – all should be good.
Sometimes “Ownerless group policy configuration failed. Failure in configuring ownerless groups policy” is a permissions issue
SharePoint admin, Teams admin: cannot configure Ownerless Groups Policy
Global admin: yes, can configure Ownerless Microsoft 365 Groups Policy.
What is the minimum role required?
According to a recent update of the Microsoft’s article – “A Global administrator can create a policy…”. In my experience – groups admin can also configure the policy

Note: Groups admin when configuring the policy can see warning message “You don’t have permissions to save changes”.
No worries 🙂 => You will be able to save changes 🙂

Video tutorial on the policy configuration (at around 5:00 you can see this error message):

Manage Microsoft 365 groups membership with PowerShell and Graph API

1 Reply

As SharePoint or Teams admin you manage Microsoft 365 groups (create, update, delete, manage membership etc.) having your admin role activated. I prefer PowerShell 7 and Microsoft.Graph PowerShell module, and I need an Azure registered app with “Group.ReadWrite.All” Microsoft Graph API delegated permission.

Some findings:

If a user was not a group member or group owner – and the user is added to the group members – this user will get notification “You’ve joined the <Group Name> group” via e-mail that comes from a group e-mail address.

When a user is added to the group owners (or elevated to group owner if user was a group member) – user does not get notification.

When a user was a group owner and now you are adding this user to the group members – user does not get notification.

All the actions are logged into Microsoft 365 audit log under your personal Id.

Script samples:

# This script is just a sample to demonstrate basic technique on getting, updating groups membership and deletion m365 groups with PowerShell and MS Graph
#
# please do not run this script as is, but update it based on your needs

# authentication with personal Id
#  app must have as minimum "Group.ReadWrite.All" Microsoft Graph API delegated permission
#  user must have SharePoint admin (or Teams admin) roles activated
Connect-MgGraph -ClientId $clientid -TenantId $tenantId 
Get-MgContext | Select-Object Scopes -ExpandProperty Scopes

# sample data
$groups = @()
$groups += [PSCustomObject]@{GroupId = '443d22ae-683a-4fe4-8875-7bd78227a026' }
$groups += [PSCustomObject]@{GroupId = 'e5805388-c18c-48c0-b42d-6223cf8f3d82' }

# Get Groups
foreach ($group in $groups) {
    Get-MgGroup -GroupId $group.GroupId
}

# add members to the group
$groupId = '443d22ae-683a-4fe4-8875-7bd78227a026'
$userId = 'df74e0d3-d78c-495b-b47a-549437d93cf7' # Adele
New-MgGroupMember -GroupId $groupId -DirectoryObjectId $userId

# add Owner to the group
$groupId = '443d22ae-683a-4fe4-8875-7bd78227a026'
$userId = 'eacd52fb-5ae0-45ec-9d17-5ded9a0b9756' # Megan
New-MgGroupOwner -GroupId $groupId -DirectoryObjectId $userId

# Delete group
$groupId = '443d22ae-683a-4fe4-8875-7bd78227a026'
Remove-MgGroup -GroupId $groupId

References

PowerShell Script Sample at GitHub

Microsoft 365 ownerless group policy to send more than 10,000 notifications

1 Reply

It is known that a single Microsoft Exchange account is not sending more than 10k emails per day.

It is also know that once activated – Microsoft 365 groups ownerless policy will be sending notifications for all groups in scope to specified number of group members within 24 hours.

The question is: what if there are more than 10,000 notifications to send (e.g. 4,000 ownerless groups and the policy is configured to send notification to 3 members per group – that gives us 12,000 notifications to send)? Would the policy send 10k notifications and the rest 2k notifications the next day?

I’m conducting an experiment. I created 10k groups in my lab tenant with one owner and 3 random members. Then I configured a policy that is sending notification to a 3 most active members (in this case – random members). And then I made all these groups ownerless by deleting the single owner Id from Azure AD (Microsoft Entra).

Here is what I got from users perspective:

user	user groups number	got messages day 1	got messages day 2	got messages total
1 Roger	5012			1374
2 Dick	5039			1349
3 Bob	5108			3412
4 Bapu	4908			1376
5 Stas	4996			1437
6 David	4959			1377
total				10325

Here is what audit log says:

Events “OwnerlessGroupNotified” day 1: 4949
Events “OwnerlessGroupNotified” day 2: 95
Events “OwnerlessGroupNotified” total: 5044
Each event details says 3 members were notified.

It seems like groups are selected by policy in random order.

Massive E-mails sending was started 43 minutes after midnight UTC

“OwnerlessGroupNotified” were logged at the rate of
1925 events during 1-st hour,
2029 events during 2-nd hour,
785 events during 3-rd hour,
176 events during 4-th hour,
26 events during 5-24 th hour,
95 events during next 25-48 hours
so max rate was one event every 3 seconds in the beginning (or 1 e-mail per second) …

TBC…

Ownerless Microsoft 365 groups policy in large environments

2 Replies

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.