Forum Discussion

Jorn's avatar
Jorn
Copper Contributor
Oct 02, 2026

Applying Search Schema fails

Hi everyone,

 

We've been fighting a SharePoint Online search issue at one of our customers since early July 2026. We've had a Microsoft Support case open for a few months, but it has hit a dead end. I'm posting here to find out whether others are seeing the same thing and whether anyone has found a workaround.

 

Our setup

  • An in-house ERP system syncs customers and projects to a SharePoint list, which serves as the provisioning master list.
  • A provisioning engine (PnP PowerShell / PnP provisioning templates) creates a site for each item, using one of two templates: Customer site or Project site.
  • During provisioning we apply:
    • Property bag values at site level (for example, the account manager for a customer)
    • Custom columns in the document libraries for document metadata
    • SearchSettings in the XML template that map both the property bags and the columns to the default RefinableStringXX managed properties
  • Some values link to managed metadata, and some are free text.

 

This approach was designed together with the customer, and Microsoft Support confirmed that it is a supported implementation.

 

The issue

  1. Applying the SearchSettings fails. Running Invoke-PnPSiteTemplate with the SearchSettings section returns one of these:
    1. Service unavailable now, please try again later.
    2. The request was canceled due to the configured HttpClient.Timeout of 100 seconds elapsing.
    3. Without SearchSettings, the template applies without problems. Even applying only the first line of the SearchSettings on a brand-new site causes the timeout.
  2. The Search Schema pages are extremely slow at both site collection and tenant level, much slower than in any other tenant we work in.
    1. The issue has now gotten worse. We can't create, modify or delete any managed property mapping, at either site collection or tenant level. Opening _layouts/15/selectcrawledproperty.aspx (for example, to edit RefinableString01) now always returns "Sorry, something went wrong. An unexpected error has occurred."

 

What Microsoft Support told us

  • At first, the case was pushed back as out of scope because we use PnP.
  • After escalation, engineering confirmed that the behaviour matches a known issue: Search Schema pages load slowly when a large number of implicit properties and mappings exist.
  • They confirmed it's not caused by misconfiguration on our side.
  • However, there is no public documentation, no workaround, no fix and no ETA, and no further escalation path. They suggested we give feedback through the community, so here we are.

 

Questions for the community

  1. Has anyone else run into this Search Schema latency or the "Service unavailable" error when applying SearchSettings, especially in tenants with many sites and mappings?
  2. Has anyone been able to reduce the number of implicit or crawled properties in a tenant, or "reset" the site-level search configuration, and did that help?
  3. Could this be related to the recent search migration issues reported in service health SP1393483 and in this thread?
  4. Are there any best practices or (unofficial) limits for the number of property bag values or library columns mapped to RefinableStrings across many sites? For example, does linking to managed metadata make it better or worse?
  5. Has anyone tried splitting the SearchSettings into smaller increments and applying them one by one?

 

We're also looking at reducing the number of mappings and the number of sites that need search support. Still, it would be very helpful to understand the actual limit we're hitting, since this affects how we design future solutions as well.

 

Thanks in advance for any insights!

No RepliesBe the first to reply