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!

Microsoft365
SharePoint Online
Sites

3 Replies

  • OwenLanty's avatar
    OwenLanty
    Brass Contributor
    Oct 10, 2026

    Since Microsoft has confirmed a service-side issue and the same SearchSettings block times out even on a new site, increasing the PnP timeout or splitting one mapping into many calls is unlikely to be a durable fix. It may simply leave a partly applied schema that is harder to audit.

    For new sites, I would temporarily remove SearchSettings from the provisioning transaction so the rest of the site can be created successfully. Record the site URL, intended crawled-to-managed property mappings, template version, and provisioning time in a remediation queue. Retry the search configuration only after Microsoft confirms recovery, and make the retry idempotent so it checks an existing mapping before writing it.

    For the current support case, provide one minimal site and one single failing mapping, together with the request correlation ID and UTC time from both the UI and automation attempt. Ask support to associate the case with the known engineering incident and provide service-side progress. Avoid repeatedly opening or writing the tenant schema during the degraded period, because that adds load without addressing the confirmed backend latency.

  • DaveMehr365's avatar
    DaveMehr365
    MVP
    Oct 05, 2026

    Hi Jorn​ 

    There are currently some known issues with the search function, particularly with the mapping of crawled properties:

    https://github.com/microsoft-search/pnp-modern-search/discussions/4946 

     

    We were able to perform the mappings using the following entry:

    https://www.linkedin.com/posts/i-have-finally-found-some-time-to-test-if-share-7501012860148412416-fwkb/?utm_source=share&utm_medium=member_desktop&rcm=ACoAACsPwMEB-1xYPbUqXNwk05ZiaM5Znc4xqWE 

    However, before we could use PowerShell, we had to map an existing SharePoint standard property; after that, PowerShell worked as well.

     

    Best, Dave

    • Jorn's avatar
      Jorn
      Copper Contributor
      Oct 08, 2026

      Hi DaveMehr365​ 

       

      Thanks for your answer!

      This is a nice workaround for one of my other customers, but this case is something different than the issue you described. 

       

      At my customer, we use PnP XML provisioning template to create all the necessary search schema configurations. We choose to do this at site level, since we configured custom propertybags on this sharepoint site and couldn't find them in the admin center.

       

      The issue we face now is that the "import" job of the search schema config, goes into timeout and then fails with the generic error "Service unavailable, please try again later".

       

      Microsoft confirmed in our ticket that this is global issue and is being experienced in several tenants. Right now, we skip the search schema import but this has a huge "impact" for our customer. That is why we are trying to look for a workaround... 

       

      Microsoft told us that, they will need at least three months in order to have this issue fixed :/

      Our customer is not satisfied with the fact that they have to wait so long for fix, since this is the basis if how they work everyday with our system...