Sep 08 2022 12:12 AM
As of August 26th critical software in our company started to fail.
All functionality involving getting results from Microsoft SharePoint Search failed to get any results.
This software is PowerShell, .NET Console applications, Runbooks (PowerShell), .NET Web API in an Azure App Service, ...
All this software - that was failing - was using an Application Registration with either a certificate or password.
To fully troubleshoot, I created a .NET Console application with no frameworks (like PnpCore SDK, Pnp.Framework, ...) but a simple HttpClient to get results from https://tenant.sharepoint.com/_api/search/query?...
This httpclient would have Bearer authorization, with an access token from either a PublicClientApplication (delegated permissions), or a ConfidentialClientApplication (application permissions)
The results were that delegated permissions always give the right results.
Application permissions however gave results when searching on "Title:", but gave no results (PrimaryResults were empty) when searching on any other: in our case: "{searchtext} Path:https://tenant.sharepoint.com/sites/X/Lists/Y/*"
At first we thought this was caused by searching on RefinableString00 and RefinableString01, but searching without specifying a managed property, fails as well.
Before August 26th, all was working just fine.
Appearantly, Microsoft deployed a patch to SharePoint Search somewhere around that date, to improve performance.
This caused incident #MO420476 to rise, but was fixed later on. However, our problems still exist, so this might not be related (although I would like to believe it does)
This issue caused me to have all applications to be reverted to delegated permissions (which in some cases is not preferrable at all, especially for f.i. runbooks).
Is there anyone, either having this issue as well, or either be able to help me solve this issue?
Best regards
Sep 09 2022 05:18 AM
Just to add:
Application Permissions:
Path:https://tenant.sharepoint.com/sites/oursite/Lists/thelist/DispForm.aspx?ID=0000
0 Results
Delegated Permissions:
Path:https://tenant.sharepoint.com/sites/oursite/Lists/thelist/DispForm.aspx?ID=0000
1 Result
Additionally: we already created a new ClientId (Application Registration) to rule that out.
Sep 09 2022 05:58 AM
Can you make sure that you have given following permission under "Application Permission" in your Azure AD App registration?
Sep 09 2022 06:03 AM
Sep 13 2022 12:23 AM
We are seeing similar issues and found that no results are being returned by the API, yet when I log on as a user I see the results without issue.
Its looks like Microsoft have disabled search for App Registrations as all results show Zero count
Sep 13 2022 01:29 AM
Have you been able to get any Microsoft Support on this?
I've tried, but with no success.
Sep 13 2022 04:59 AM - edited Sep 13 2022 05:03 AM
We're having the exact same issue over here! Search returning 0 results when signed in using Certificate / Application Only (with Sites.FullControl.All scope)
Multiple results though when running in delegated mode.
This is not continuous though. Sometimes we do get search results.
Sep 13 2022 05:07 AM
Sep 13 2022 05:26 AM
Sep 13 2022 01:16 PM
We have as you would expect raised it with Microsoft Support but it will take days to escalated this to a level where someone will actually understand the issue.
Microsoft appear tp have been having issues with Search for the last few months and the SLA of 25QPS per tenant is actually more like 5QPS and now appears to have been switched off completely. I read that it was something to do with the OneDrive content also bein queries as part of the same index and this was the cause. To this effect I believe they have now added a Site.Selected as an new permission level.
Today,
- delegated search as a user works
- App registration via Azure AD returns 0 results
- SharePoint Admin App Registration returns 0 results
- Site.Selected registration (add a list of sites) yet to be tested
We are going to try remove MFA today for a group of users and run each search through the pool of users cycling through the list to ensure we don't get throttled. A lot of work for something that the is no documentation to day its broke.
In the mean time today as I know it works as a delegated user I will create a pool of users
Sep 13 2022 01:23 PM
Sep 13 2022 02:03 PM
I also created a . NET core console application to test an HTTP call directly to the API (to test without packages, like Pnp), with both GET and POST.
Both HTTP verbs have the same results in respect of application and delegated permissions.
In other words: switching to POST instead of GET does not solve the issue.
Sep 13 2022 03:39 PM
Sep 13 2022 06:08 PM
Sep 14 2022 12:51 AM
Sep 14 2022 01:53 AM
Sep 14 2022 02:03 AM
Sep 14 2022 05:57 AM
We have the same problem, we have provisionally solved it by switching to authentication via service user but it is obviously not a solution. Has anyone tried registering an application with the old add-in model as I understand it is suggested here?
https://docs.microsoft.com/en-us/sharepoint/dev/solution-guidance/security-apponly
Sep 14 2022 09:04 AM
Sep 14 2022 09:33 AM