Category Archives: Software

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.

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

LAMP project migration

Leave a reply

I have been involved in a birdwatching community web project for a long time. At the moment it has 250k pictures, 2500 blog posts from community members.

The site is a custom development – written by Askar Issabekov with php and MySQL and hosted under Dreamhost dedicated server.

Initially the migration plan was

  • get and configure new hosting
  • copy php scripts and media files
  • backup/restore MySQL databases
  • update hosts files and ensure everything works good
  • set source site in “maintenance” mode
    • put notification on the site header
    • set databases in read-only mode
  • backup/restore MySQL databases again
  • copy media files delta
  • set databases in r/w mode
  • ensure everything works good
  • change DNS from old host to new host

Some more data:

  • MySQL database: 120 MB

It turned out that

  • Source host uses Apache and target host uses Nginx
  • phpMyAdmin cannot import database from SQL backup

So we ended up the following

  • backup and document existing environment
  • get and configure new hosting
    • ensure php version is the same
  • copy php scripts and media files
    • remove all .htaccess and update nginx config files accordingly,
      e.g. Index etc.
    • fix files permissions (chmod)
  • backup/restore MySQL databases
    • if the database is big
      • – consider splitting database – a few tables each backup/restore
      • – consider zipping database while export-import
    • if phpMyAdmin fails – use command-line mysql
    • update database connections (user names, passwords, database names and hosts)
      as temporary measure – it is possible to allow access to old host databases from new host ip
  • update hosts files and ensure everything works good
  • set source site in “maintenance” mode
    • put notification on the site header
    • set databases in read-only mode
  • backup/restore MySQL databases again
  • set databases in r/w mode
  • copy media files delta
  • ensure everything works good
  • change DNS from old host to new host

Question: to avoid hassles with hosts files – is it possible to use a different real target name, then after verifying everything works good – change name

We’d also need to take care of e-mail migration

(WIP)

Microsoft 365 Search: built-in people search by nickname

1 Reply

Did Microsoft silently implement nickname search?

E.g.

I have created a user “Robert Dylan” and never used name “Bob”, but search understands that I’m looking for Robert Dylan when I’m searching for Bob or Bob Dylan or Bobby.

Important thing – result is shown under “All” and “People” verticals.

I know Microsoft claimed m365 search is backed by Turing technology – it understands you, answers your question but not just blindly display keyword occurences (announcement at Ignite Spring, more on Ignite Fall 2021)… So is that it?

But the same trick did not work with Dick for Richard or (of course) Syd for Roger Barrett:

Please check “How to configure Microsoft 365 People Search by Nickname and Full Name“

SPO Site LastContentModifiedDate vs LastItemModifiedDate vs LastItemUserModifiedDate vs Graph LastModifiedDateTime

2 Replies

How do we know when the SharePoint site was last updated?

We have multiple “when the site was modified last time” properties – e.g. some we can retrieve with SharePoint CSOM:

  • Site LastContentModifiedDate
  • Web LastItemModifiedDate
  • Web LastItemUserModifiedDate

Also we can get

  • MS Graph site object with LastModifiedDateTime property
  • get usage reports via Microsoft Graph (activity reports), and
  • use “Last activity” field via Admin Center GUI

On the other hand – we can view and modify site in multiple ways – visit site home page, open and/or update document/list item, change site/library settings, configure site permissions, assign site sensitivity label, setup site property and so on.

Question: which site “last modified” or “last activity” properties reflect what events/actions?

This might be important if we think of retention policies, or any kind of clean-up processes… Let say, we are getting report on abandoned sites (inactive sites), but we are also assigning sites sensitivity labels, or we are updating site custom properties (e.g. for adaptive scopes), we have an ownerless groups policy working etc.

What if we assign site sensitivity label to an old inactive (5 years old) site – would it affect retention policy since site was updated this way?

Results

So i did some tests and based on detailed results below, it seems like

  • Web LastItemModifiedDate is triggered when user just visited site (but property LastItemUserModifiedDate is not triggered)
  • If a document or list Item updated by user or app – all properties are triggered
  • MS Graph site property LastModifiedDateTime, root web property LastItemModifiedDate and Site LastContentModifiedDate – same values
  • If site custom property is updated – it does not affect any site “last modified” property
  • The same for sensitivity label updated by app – it does not affect any site “last modified” property
  • The same for Microsoft ownerless groups policy – when user accept or decline group membership – no site “last modified” properties are changed (the same is true for Microsoft 365 group last modified date/time property).

Please refer to the table below

Detailed test results

Test results if the event triggers property update:

EventLast Content Modified DateLast Item Modified DateLast Item User Modified DateGraph Last Modified DateTimeGUI Last activity
Page viewed by userYesYesNoYes
Home Page viewed by user
Site Page viewed by user
Document or list item updated by userYesYesYesYes
Document or list item updated by appYesYesYesYes
Site config settings updated by user
Site config settings updated by app
Site custom property updated by appNoNoNoNo
Site Sensitivity label updated by user via SharePointYesNoNoNo
Site/Group Sensitivity label updated by user via Teams
Site/Group Sensitivity label updated by user via AzureNoNoNoNo
Site Sensitivity label updated by appNoNoNoNo
Site collection admin updated by userYesYesNoYes
Site collection admin updated by appYesYesNoYes
SharePoint group membership updated by userYesYesNoYes
Standalone Site connected to a group by userYesYesYesYes
Add Microsoft Teams to Site by UserYesYesYesYes
Update m365 group membership via M365 admin console by adminYesYesNoYes
Update m365 group membership via Azure by admin
Update m365 group membership via Teams by userNoNoNoYes
Update m365 group membership via App
Accept group ownership invitation sent by ownerless groups policyNoNoNoNo
Decline group ownership invitation sent by ownerless groups policyNoNoNoNo

Using Path property in Microsoft 365 Search Query

1 Reply

Using Path property in Microsoft 365 Search Query was kind of ambiguous. But now Microsoft implemented update and clarified some details. So below are some tips and tricks on filtering by site Url (path) in query field in Microsoft 365 Search verticals.

Path filter with trailing slash (“/”)

In November 2022 Microsoft rolled out an update for multiple search features, including checks on the path managed property for a trailing slash. Previously path filters were valid with and without trailing slashes.

Consider the following scenario.

Given the path filter with the contain operator (“:”) 

Path:https://contoso.sharepoint.com/sites/MySite

These path could be matched with:

Path:https://contoso.sharepoint.com/sites/MySite
Path:https://contoso.sharepoint.com/sites/MySite/subsite
Path:https://contoso.sharepoint.com/sites/MySite2
Path:https://contoso.sharepoint.com/sites/MySite2/subsite
Path:https://contoso.sharepoint.com/sites/MySite3

Obviously, the match intent is unclear. Adding a trailing slash clarifies that only MySite (and below) matches. So intended matches would be only:

Path:https://contoso.sharepoint.com/sites/MySite
Path:https://contoso.sharepoint.com/sites/MySite/subsite

Using SPSiteUrl property

The other option – use the SPSiteUrl property with the full path:

SPSiteUrl:https://contoso.sharepoint.com/sites/MySite

SPSiteUrl and Path properties use different matching strategies. When using contains operator (colon sign “:”) – SPSiteUrl will match the full value, while Path will do a “starts with” match.

DepartmentId

DepartmentId is a search managed property used under Hub sites and propagated through all associated sites content.

That means if we want to scope down search to hub site with it’s content – we can use DepartmentId property, e.g.

DepartmentId=4965d9be-929b-411a-9281-5662f5e09d49

instead of iteration through all hub sites and using path: property.

Microsoft 365 Retention Policies SharePoint Adaptive Scopes Advanced Query

1 Reply

Basic query is available as GUI:

where you can use objects: “Site Url”, “Site Name” and “Refinable String 0″..”Refinable String 99”. Conditions would be “is equal to”, “is not equal to”, “starts with” and “not starts with”. Or you can select “Advanced query builder” and enter KQL query.

Advanced query builder

Advanced query builder allows us to use more site properties then “Site Url”, “Site Name” and “Refinable Strings” and more conditions than “is (not) equal to” and “(not) starts with”.

E.g. we can use “Title”, “Created”, “Modified” site properties and “=”,”:”,”<“, “>”, “<=”, “>=” conditions.

Working queries examples: 

created>=2022-07-21
modified>1/31/2023
created>12/31/2021 AND modified>=7/31/2022
created<=2020-11-15 OR modified>2023-02-06 (?)
created<=2020-1-15 OR modified>2023-01-31 (?)
created<=11/15/2020 OR modified>1/31/2023
title:test
SiteTitle:test
RefinableString09:Test*
RefinableString09<>Test
RefinableString09=Birding AND RefinableString08<>Included

Not working queries examples:

site:https://contoso.sharepoint.com/sites/test* 
RefinableString11 = Birds # (do not use spaces in advanced query)
Path:https://contoso-my.sharepoint.com
Template:STS
Template:"SITEPAGEPUBLISHING#0"
Template:SITEPAGEPUBLISHING*
? RefinableString09<>Birding AND RefinableString08:Official
modified>31/1/2023 (should be like modified>2023-01-31
)

Query against custom site property (aka property bag value)

You can create custom site property and assign value to the property with
Set-PnPAdaptiveScopeProperty or Set-PnPPropertyBagValue.
Property must be with “Indexed” parameter. Once the property is set up, m365 search crawls site and creates crawled property. Then you map crawled property to some pre-created refinable string managed property. You can assign alias to this managed property.

In my test scenario I used RefinableString09 with alias SiteCustomSubject.

Site property valueQueryresult
BirdingRefinableString09:Birddoes not work
BirdingSiteCustomSubject:Birddoes not work
BirdingRefinableString09:Bird*works
BirdingSiteCustomSubject:Bird*does not work
BirdingRefinableString09:Birdingworks
BirdingSiteCustomSubject:Birdingdoes not work
BirdingRefinableString09:Birding*works
BirdingRefinableString09=Birdingworks
BirdingRefinableString09=Birddoes not work
BirdingRefinableString09=Bird*does not work
BirdingSiteCustomSubject=Birdingdoes not work
RefinableString09<>Birdingworks
RefinableString09=Birding AND RefinableString08<>Includedworks

Query against multi-value property.

Site property valueQueryresult
TestA TestBRefinableString09:TestAworks
TestA TestBRefinableString09 = ‘TestA TestB’does not work
TestA TestB??? RefinableString09=’Test10 Test5′does not work
TestA TestBRefinableString09:TestB ?
TestA,TestBRefinableString09:Test*works
TestA,TestBRefinableString09=Test*does not work
TestA,TestBRefinableString09:Testdoes not work
TestA,TestB
TestA;TestB
TestB TestA
TestA TestB		RefinableString09:TestBworks
TestA, TestB
TestB,TestA
TestA TestB		RefinableString09=TestAdoes not work
TestA,TestB(basic) RefinableString09 starts with testworks

Some more findings

Modify adaptive scope

If you need to modify adaptive scope – you’d better delete it and create a new one. The reason – if you want to validate what sites are included in scope with GUI – via button “Scope details” – you want to see only sites that are in scope, but that’s not the case when you modify the scope, because if you modify the scope – you’d see sites that are not in scope with “Removed” status.

Alternatively you can use filter to filter out removed from scope sites.

what else?

What is the takeaway from this for SharePoint administrators? We would be asked to configure SharePoint the way compliance…

References

Adaptive scopes Retention Policies Data Lifecycle Purview

SharePoint Sites Lookup

Leave a reply

That’s a very common problem in SharePoint world. You are looking for a site owner but there is no tool available for regular user to find who owns the site.

Scenarios.

You get a link to some SharePoint site, but you do not have access to it. You requested access but nobody has responded. You need to find who is the site owner.

(To be continued)