Search API with Application Permissions returns no results, Delegated permissions do

[StevenDeRoover]

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

[#2]

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.

[#3]

@StevenDeRoover 

Can you make sure that you have given following permission under "Application Permission"  in your Azure AD App registration?

[#4]

I've given all SharePoint permissions I could give, for both Application and Delegated permissions.

Also, all was working fine untill August 26th, while nothing had changed on our side, so something must have changed at the SharePoint Search API server side.

[#5]

@StevenDeRoover 

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

[#6]

@butchersoft585 

Have you been able to get any Microsoft Support on this?

I've tried, but with no success.

[#7]

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.

[#8]

We had that case too: having results at some point, no results the other. After a few days, nothing returned, continuously.
As if SharePoint Search simply started running dry (I reckon because of crawling started returning nothing, from time to time, with no results anymore in the end?)

[#9]

Do you have any idea how we can report this to Microsoft, besides posting in here?
I've tried Free Microsoft Support, but they only support out-of-the-box issues (fi not being able to log in to SharePoint, or something like that).
I've tried creating a Pay-Per-Incident, but I'm unable to add a subscription over there.
Leading all support to a dead end.

[#10]

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

[#11]

Probably worth mentioning that the problem exists with (all tested and failed)
- Microsoft.SharePoint.Client.dll
- Pnp.Search
- REST API directly
All user the same endpoint at the end of the day.

[#12]

@butchersoft585 

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.

[#13]

Update
- Site.Selected registration (add a list of sites) - even with full control does not allow search permissions to run.

[#14]

Update - changed our application to run under a delegated user using a username and password through PNP Enterprise App registration and now getting results back!!!. Now we just have to worry about throttling. The user had to have MFA disabled

[#15]

That's what we are doing as well, unfortunately, we don't have only one application, but multiple, and not all able tot run under delegated permissions.

I sincerely hope this is getting pickup by Microsoft, as 50% of their Search API is out of service, for multiple distinguished tenants.
Maybe there are more out there, but did not find their way to this forum.

[#16]

Yes, searching using delegated permissions fortunately works fine, but that's not a solution, it's a workaround at most.
Good that you raised an issue with MS support. We will too, let's see if it gets is somewhere.

[#17]

Most far I could get, is this forum, and a link to the Services Hub, where I can do absolutely nothing.
And besides, why should I be paying for a PayPerIncident, if Microsoft screwed up?

[#18]

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

[#19]

My client is currently experiencing this same issue. The search being conducted has worked for years without issue. It is queried via CSOM using a application ClientId and ClientSecret. The application has FullControl across the SharePoint tenant.

I can conduct an identical search with my user account and get the exact desired results.

Currently for the application, the the result count is 57 whereas it should be 98 - I imagine that will continue to drop towards 0 as the crawl progresses.

[#20]

A question to all of us: which region are we in? Maybe Microsoft can narrow down.
I am from Belgium, so West-Europe, Roman Standard Time.