SharePoint for Office 365 Search Center Bug – How is My Tenant Affected?

Posted by PJ Wise on October 1, 2018

Find me on:

The message – “Administrators may be unable to perform changes to search schema 47036056_ssettings” may appear in Office 365 search health.  What does it mean?

A few months ago, we noticed a discrepancy between the items a custom webpart of ours was displaying and what should appear. We were filtering based on content types or attempting to anyway.

What Went Wrong?
I dug around in the network tab for a few minutes and only found that the query we were making clearly had a restriction of “ContentType: ‘Site Page’” on it. I was still seeing erroneous results with other content types from the query, so I looked at the items that shouldn’t be showing up, specifically a Site Page derivative titled Test-News-Item-6. Just as I thought, it was set to the content type OWv2News:

Content Ype Issue_1

Our query was explicitly filtering all results except those with a ContentType of Site Page so, based on what SharePoint is telling us, this item shouldn’t be coming back. Now, this item had at one point been a Site Page and was changed to OWv2News, so we trigger a crawl and come back a day or two later. Same result. We check for service advisories regarding SharePoint search. Nothing.

Our custom webpart was on the home page of a pretty large client, so resolving this or at least understanding the problem was becoming increasingly important. At this point I had already replicated the issue in our development environment so we could have free reign on all every setting and access to every page. Let’s dig deeper!

We already know that the item is showing the OWv2News Content Type in the SharePoint interface. The next step is to brush the dust off the trusty SharePoint Search Query Tool. We already know that this page “Test-News-Item-6” is causing problems, so we set that as our query text and select the Title and ContentType.

Screen Shot 2018-10-01 at 12.14.31 PM

Our item comes back and right away we can see the Content Type difference between what SharePoint was telling us in the front-end and what the metadata of the item actually was.

Screen Shot 2018-10-01 at 12.15.05 PM

What Is Going On Here?
By some deficiency in SharePoint’s crawler the content type change on the front-end never resulted in a change of the item’s metadata. Since our custom webpart uses SharePoint search it was grabbing that metadata, so from its frame of reference everything was working as intended. Of course, from our client’s frame of reference nothing was working.


How To Fix It?
No amount of changing the content type back and forth and forcing site and library reindexes resolved the metadata issue. Editing our webpart to use a different search endpoint seemed a little out of scope since the issue appeared to be on Microsoft’s side. I gathered a few examples of where this issue had occurred, including expected content types, actual content types, urls, and reproduction steps. We sent them off to Microsoft through their ticketing system. After some back-and-forth between Microsoft and our product manager we were told to check for a service advisory in our tenants in the “Service health” page.


Admin Portal -> Health -> Service Health -> Advisories -> SharePoint Online

content type issue 2

Status: Service degradation

User Impact: Administrators may be unable to perform changes to search schema settings.

Title: Issues with search schema settings

User Impact: Administrators may be unable to perform changes to search schema settings.

Current status: We identified a code issue that caused the infrastructure responsible for search schema administration to become degraded. In order to prevent more severe impact to the service, we've disabled the affected search schema setting functionality while we develop and deploy a solution. We anticipate that the development and deployment of the fix to address the underlying root cause will complete by 10:00 PM UTC on Friday, October 19, 2018.

Scope of impact: This issue may potentially affect any of your administrators attempting to change search schema settings.

Start time: Friday, September 21, 2018, at 6:00 AM UTC

Estimated time to resolve: We expect that the deployment of the fix will complete by 10:00 PM UTC on Friday, October 19, 2018.

Preliminary root cause: A code issue caused the infrastructure responsible for search and indexing to become degraded.

We asked a few other developers and project managers to check their client’s tenants and everyone saw this advisory as well. No fix from Microsoft yet, but we’ve set reminders to reindex and retest this issue following their specified fix-by date. Sending clients an acknowledgment of an issue from Microsoft always helps to ease the tension.

Impact On Your Office 365 Tenant?
If you or your clients rely on content types for managing their IA consider warning them that their content type changes may not actually be occurring until this issue is resolved by Microsoft. Search queries, workflows, and anything else that uses or could use content types would be impacted by this. We’ve reached out to clients of ours who we know use content types regularly to let them know that this issue may impact their day-to-day work. 

When Will This Be Resolved?
Microsoft is reporting an estimated resolution date of Friday, October 19, 2018.  Keep checking your Office 365 tenant health dashboard for updates on this date.

Lessons Learned?
Don’t be afraid to have a healthy distrust in search results and use alternate tools to SharePoint’s interface to find out what the actual metadata is when something seems off! The SharePoint Search Query Tool was critical in discovering what the issue was here.

Also, don’t hesitate to reach out to Microsoft. As this issue shows, they are more than willing to help out. Especially if you provide examples of what is going wrong and reproduction steps so they can see if there is really a problem. This can be through the ticket system or Microsoft’s various GitHub repositories. We’ve had success talking to the people who work on these products and having our questions answered.

Topics: Office 365

PJ Wise

PJ Wise is a developer at Withum Digital contributing to client SharePoint framework projects and Withum Digital’s Software-as-a-Service turnkey intranet of OneWindow Workplace.

Leave a Comment: