Tag Archives: Ownerless groups policy

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

More on Microsoft 365 ownerless groups

Massive Microsoft 365 groups update with PowerShell

Leave a reply

What if you need to update thousands of m365 groups? E.g. membership – to add a group owner or member.

In my case, it was Microsoft 365 ownerless groups policy… Details are here but in short, I needed to update ownership for 10,000 m365 groups adding 10 accounts to group owners, 1,000 groups per account.

And I figured out for myself that the fastest way is to use Microsoft Graph API with PowerShell parallel trick. Here is the PowerShell code:

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

In my environment, 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 groups in Microsoft 365

1 Reply

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

And 9 videos :

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:

  1. 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.
  2. 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 can manage Microsoft 365 groups (create, update, delete, manage membership etc.) having your admin role activated. I use Azure registered app with “Group.ReadWrite.All” Microsoft Graph API delegated permission and Microsoft.Graph PowerShell module.

When a user was not a group member or group owner – and is added to the group members – user gets 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 is added 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 deletion m365 groups with PowerShell and MS Graph
# please do not run this script as is, but update it upon 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
# add Owner to the group
$groupId = '443d22ae-683a-4fe4-8875-7bd78227a026'
Remove-MgGroup -GroupId $groupId

https://github.com/VladilenK/m365-PowerShell/tree/main/KBA/Ownerless-Groups

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:

useruser groups
number		got messages
day 1		got messages
day 2		got messages
total
1 Roger50121374
2 Dick50391349
3 Bob51083412
4 Bapu49081376
5 Stas49961437
6 David49591377
total10325

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

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

References