Tag Archives: Microsoft 365 Governance

KBA, how-to, thoughts related to Microsoft 365 SharePoint Governance

SharePoint Governance

SharePoint Governance: list of articles

References

Restricted SharePoint Search rationale

The problem background

When you have a really big number of sites – it is very difficult to keep them all in a well-managed state, e.g. to have reasonable (minimal) permissions provided to each site. So the typical situation (unfortunately) is: we have a lot of overshared sites. There are also a lot of ownerless sites where permissions are not managed. We know that search is security-trimmed, i.e. a user can get search results from content he/she already has access to. But with overshared sites – users get results they should not be able to see. With regular search experience – a user can see with his own eyes the source of the content he/she gets results from – so user can understand that results are coming from sites user should not have access to (overshared sites). But when it comes to AI-based search (Copilot) – user is getting answers, but he/she do not always know the source of that data.

So the problem is – we want to ensure Copilot is trained on a proper set of data and results are curated to users needs and access permissions. So for Copilot we really need to exclude from search scope such sites we are not sure content is valid, accurate and properly secured. We do not want users to get garbage or exposed sensitive information as an authoritative answer from Copilot.

The solution

This is where Restricted SharePoint Search feature should help, as with this feature your can restrict organization-wide search (and Copilot) to a curated list of SharePoint sites – “allowed sites” – public sites that passed attestation and where permissions are checked and data governance policies are applied, and content user work with on daily basis – his/her own documents and content shared with user directly (check details on Microsoft’s How does Restricted SharePoint Search work) – e.g. content user is supposed to have access to normally.

Excluded from search scope would be sites shared with user indirectly, e.g. something that was shared with everyone.

The root cause

Interesting, that with this feature Microsoft is not solving the real issue, but hiding (concealing) the real issue and just making Microsoft 365 to look more secure.

The real problem (root cause) is over-sharing data. But Microsoft already sold us SharePoint (and then Microsoft 365). And now Microsoft is trying to sell us Copilot, so they “solved” the over-sharing issue with “let us limit search” solution instead of “let’s fix oversharing”.

Note 1: Restricted SharePoint Search feature is free – i.e. it is included in standard Microsoft 365 license. Do not be confused with site access restriction policy – feature that require SharePoint Premium license and allows to restrict access to some SharePoint sites with specific groups only.

Note 2: I know that Microsoft is trying to address over-sharing issue as part of their SharePoint Premium (SharePoint Advanced Management) package, e.g. with AI Insights and Data access governance insights – reports that can help prevent oversharing by detecting sites that contain potentially overshared or sensitive content. With Manage content lifecycle we’d decrease amount of “garbage” or outdated content.
But SharePoint Advanced Management is licensed separately, when Restricted SharePoint Search is free.

Note 3: I know that users are an even more real problem because they tend to simplify and share information irresponsibly.

References

Dealing with Ownerless Groups in large Microsoft 365 environments

1 Reply

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

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…

Microsoft 365 retention policies: Static vs Adaptive scope

Implementing Microsoft 365 group expiration policy in large companies

2 Replies

This post is dedicated to one specific subject: implementing Microsoft 365 groups lifecycle (expiration) policy in large Microsoft 365 environments.

But this post is also a part of a bigger problem – dealing with ownerless resources in Large Microsoft 365 environments. Please refer to the umbrella post.

Scenario

You administer a large Microsoft 365 environment. Let say you have 100k users or more, 50K or more sites. Environment is not new, so after some years you have a lot of ownerless groups and sites (thousands probably), and a lot of inactive groups and sites (probably tens of thousands). You are getting more and more ownerless groups – hundreds each month. You are thinking of stopping bleeding and cleaning this up…

Implementing Microsoft 365 groups expiration policy

If you are thinking of activating in an existing environment – you would probably have a spike – all the old groups will be subject to policy. The ide is to avoid situation when a specific person – group owner will get dozens of email. It would be better if a person will receieve, let say one email per week.

Here is my 4 possible approaches to avoid this spike, distribute notifications evenly across the time and ease the pain:

By changing Group Lifetime

You would need to change the policy every, e.g. week or month, specifying group lifetime in days starting with maximum period. Consider
– calculate number of days between the oldest group created an today, plus 35 days – it’ll be your first “group lifetime”
– activate the policy with this number of days in “group lifetime” – and within a week you will get notifications on the oldest group/groups
– after a week or two – change the “group lifetime” decreasing it by e.g. 30-60 days and reactivate the policy… and so on

You can easily calculate it all and choose your pace depending on how many groups you have to renew, how much time you need to clean-up. You got the idea.

Downside – in the email notification it will be said “otherwise the group will be deleted on …”, but you joggling with lifetime period – so these dates might confuse users

By renewing groups as admin

As an admin, you can use PowerShell “Reset-PnPMicrosoft365GroupExpiration” or graph API “POST /groups/{id}/renew“ to renew any group.

So depending on total number of groups, number of active/inactive groups, number of ownerless groups in your organization – you can come up with a strategy, using one or more of the following techniques:

renew all active and known and important groups (build list of groups to re-activate based on your own criteria) and then trigger the policy
build list of definitely inactive groups and renew all other groups
split groups into chunks and every day or week (depending on numbers) renew groups in a chunk… after that you can activate groups expiration policy, the policy will be triggered against small number of groups every day/week (with this trick you would avoid policy triggering against large number of groups and sending thousands of emails at one)

By sending customized e-mails to users

Another technique to avoid surge in your e-mail system (and most importantly – avoid sudden influx of support requests) – you can send emails to group owners with a link to renew a group. Surely you’d need to build your custom solution for that, but this does not seem like a complicated task. Some PowerShell scripting – and you are good.

“Renew group” link would look like:
https://account.activedirectory.windowsazure.com/Group/RenewGroup?tenantId=<tenantId>&id=<groupId>
where <tenantId> is tenant id and <groupId> is group Id. So with PowerShell you’d just pull groups in question, their owners and send email with the link dynamically built. Consider spreading this activity across the time to avoid spikes.

By sending users to the groups page

Probably the easies option to smooth the expiration policy implementation is to send group owners to a Microsoft “Groups I own” page – where they could renew or delete their groups. The page is:

Groups I Own (https://myaccount.microsoft.com/groups/groups-i-own)

The downside is – the policy should be in active state (otherwise owners will not see when the group is expiring and option to renew it). So consider a maximum lifetime period in policy, then you’d decrease this period).

Groups expiration policy technical details

Check this KBA for a deep dive into the groups lifecycle policy technical details.

Vlad's SharePoint blog

Microsoft 365 Copilot, Teams, Azure, Search, PowerShell, Automation, Governance

Tag Archives: Microsoft 365 Governance

SharePoint Governance

SharePoint Governance: list of articles

References

Restricted SharePoint Search rationale

The problem background

The solution

The root cause

References

Dealing with Ownerless Groups in large Microsoft 365 environments

Scenario

Solution

High-level steps for group-based Sites:

SharePoint Inactive Site Policies

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

Manage Microsoft 365 groups membership with PowerShell and Graph API

References

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

Microsoft 365 retention policies: Static vs Adaptive scope

Implementing Microsoft 365 group expiration policy in large companies

Scenario

Implementing Microsoft 365 groups expiration policy

By changing Group Lifetime

By renewing groups as admin

By sending customized e-mails to users

By sending users to the groups page

Groups expiration policy technical details

Related content