Azure AI Search SharePoint indexer fails with a generic "Bad Request" when an index with a sharepointSiteUrl field receives more than 5 distinct site URLs

Taylor Hawkins 0 Reputation points
2026-11-05T20:19:33.7033333+00:00

We use Azure AI Search (API 2026-08-01-preview) with the SharePoint in Microsoft 365 indexer. ACL ingestion is on, including SharePoint groups support: sharePointConnectorAppRegistration and a SharePointSiteUrl field with sharepointSiteUrl: true. Documents are chunked with index projections into one chunk index per group.

Problem. An index whose sharepointSiteUrl field receives more than 5 distinct site URLs rejects the write. Writing a document directly through the index API returns the real error: HTTP 400, "OperationNotAllowed", with text saying the limit of 5 was exceeded. The indexer only reports "Bad Request", with no site, field or limit named. In practice, 4 sites were accepted, and the error text says 5.

What we observed

  • Cause confirmed: an index with 5 or fewer distinct site URLs indexes normally. The same sites spread across several indexes work.
  • Case sensitive and permanent: the distinct values are case-sensitive. A slot is never released, even after documents from that site are deleted. Only deleting and recreating the index frees it.
  • The indexer hides the cause: per-site indexers sharing an index all failed with "Bad Request" until we wrote a document directly to see the message. The run history doesn't show the limit anywhere.
  • No documentation: we found no mention of the 5-site limit in the SharePoint ACL or service limits pages.

Impact. We have 150+ SharePoint sites. With a limit of 5, ACL-enabled content needs about 30 indexes, one knowledge source each. A knowledge base holds at most 10 knowledge sources, so we also need several knowledge bases and an application that queries them in parallel. That adds cost and latency for what looks like a single logical corpus.

Questions

  1. Is the 5-distinct-site limit intended? Is it documented anywhere?
  2. Can it be raised, or is there a way to index many sites into one index while keeping per-user permission filtering?
  3. Can the indexer surface the real error (the limit exceeded) instead of "Bad Request"?
  4. Is the limit related to the query-time SharePoint group resolution that uses SharePointSiteUrl? If we don't use SharePoint groups support, would the cap and the separate unknown-user failure (404 "User cannot be found" on siteusers/getbyemail) both go away? What would we lose?

Related. We reported a second issue separately: the query-time 404 for the whole index when the user isn't in a site's user list - seemingly related to sharepointSiteUrl.

Azure AI Search
Azure AI Search

An Azure search service with built-in artificial intelligence capabilities that enrich information to help identify and explore relevant content at scale.

0 comments

1 answer

Sort by: Most helpful
Most helpful Newest Oldest

  1. AI answer

    2026-11-05T20:20:58.9+00:00

    For an indexed corpus that must honor SharePoint site groups, partition the sites across indexes for now and open an Azure support request to confirm whether the observed five-distinct-URL restriction can be raised; no public Microsoft documentation currently lists that restriction or a supported quota-increase procedure.

    Status of the five-site restriction

    Your direct indexing test provides a strong, reproducible service response: OperationNotAllowed when the index exceeds the service’s stated limit. However:

    • The SharePoint ACL documentation does not list a five-value limit for SharePointSiteUrl.
    • The published service-limits page does not list it as an adjustable quota.
    • The documented SharePoint ACL limit of 1,000 entries is per file and concerns users/groups in an ACL, not distinct site URLs in an index.^1^
    • ACL ingestion and SharePoint group enforcement remain preview features, which can be constrained or changed before general availability.^2^

    Consequently, the available public material cannot establish whether five is an intended permanent limit, a preview safeguard, or a defect. It also does not document case sensitivity, slot persistence, or a way to reclaim a URL without recreating the index.

    Supported architecture choices

    1. Keep SharePoint site groups: shard the indexed corpus

    If permissions depend on SharePoint Owners, Members, Visitors, or custom site groups, retain:

    • sharePointConnectorAppRegistration
    • SharePointSiteUrl with sharepointSiteUrl: true
    • metadata_spo_site_url mapped or projected onto every chunk
    • UserIds and GroupIds
    • permissionFilterOption: "enabled"

    These elements activate server-side SharePoint group resolution.^2^

    Given the behavior you reproduced, keep each index within the reported limit and canonicalize URL casing before ingestion so the same site cannot consume multiple distinct values. Because deletion has not released slots in your testing, treat index recreation as the only demonstrated reset—not as documented product behavior.

    A knowledge base can query multiple knowledge sources in one retrieval request; the engine generates subqueries and merges the results.^3^ The maximum is 10 knowledge sources per knowledge base on most paid tiers, while service-wide knowledge-source and index limits vary by tier.^4^ With approximately 30 indexes, multiple knowledge bases—or another fan-out layer—would still be required.

    2. If SharePoint site groups are unnecessary: remove their configuration

    SharePointSiteUrl is specifically used at query time to determine the site against which Azure AI Search resolves the caller’s SharePoint group memberships. The service then compares the resolved memberships with spg:-prefixed values in GroupIds.^1^

    If your permissions can be represented entirely by:

    • directly assigned Microsoft Entra users, and
    • Microsoft Entra security or Microsoft 365 groups,

    then create a new index without:

    • sharePointConnectorAppRegistration
    • the sharepointSiteUrl: true field
    • the metadata_spo_site_url mapping/projection

    Keep ACL ingestion, UserIds, GroupIds, and permission filtering enabled. Microsoft Entra group membership is resolved through Microsoft Graph and does not require per-site SharePoint group resolution.^1^

    You would lose authorization paths that depend on:

    • SharePoint Owners/Members/Visitors groups
    • custom SharePoint site groups
    • spg: permission entries

    Also note that Microsoft Entra groups nested inside SharePoint groups aren't expanded even when SharePoint group support is enabled.^2^

    Because removing this configuration removes the documented site-specific group-resolution operation, it should also remove that operation’s dependency on looking up the user in each site. However, the exact siteusers/getbyemail 404 behavior and its remediation are not documented in the available Microsoft material, so this should be validated on a new test index before redesigning the full corpus.

    3. Consider a remote SharePoint knowledge source

    For scenarios requiring the full SharePoint permission model, sensitivity labels, and built-in security trimming, Microsoft recommends a remote SharePoint knowledge source. It queries SharePoint through the Copilot Retrieval API under the caller’s identity, uses no Azure AI Search index, and can be scoped using URL filters.^5^

    This avoids index sharding around indexed SharePointSiteUrl values, but it changes the architecture:

    • content is retrieved live rather than replicated;
    • only textual content is queried;
    • the caller must be recognized by both the Azure and Microsoft 365 tenants;
    • it remains a preview capability.

    Indexer error reporting and escalation

    Indexer execution status is designed to expose document key, operation name, message, details, and documentation link when available.^6^ Since this case collapses the actionable OperationNotAllowed response into Bad Request, configuration changes such as maxFailedItems will not correct the underlying rejection or improve its text.

    Open an Azure support request and include:

    1. API version and region/tier.
    2. Sanitized index, indexer, skillset, and projection definitions.
    3. UTC timestamps and correlation/request IDs.
    4. Full direct-indexing 400 response showing OperationNotAllowed.
    5. Indexer execution-history response showing only Bad Request.
    6. Minimal reproduction using five accepted canonical URLs followed by the rejected next distinct URL.
    7. Evidence that deletion does not release a value and recreation does.
    8. A request to confirm:
      • whether the limit is intentional;
      • whether it is adjustable;
      • whether case-sensitive permanent accounting is expected;
      • whether the indexer should propagate the detailed service error.

    Do not include access tokens, API keys, secrets, user identities, or tenant-specific URLs in the support package.^7^

    References

    1. Query-time ACL and RBAC enforcement in Azure AI Search (preview)
    2. Use a SharePoint Indexer to Ingest Permission Metadata - Azure AI Search
    3. What is a knowledge source?
    4. Service limits in Azure AI Search
    5. Create a remote SharePoint knowledge source (preview) (rest)
    6. Indexer Errors and Warnings - Azure AI Search | Microsoft Learn
    7. Troubleshoot SharePoint permission filtering in Azure AI Search (preview)
    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.