Can no longer create indexers with executionEnvironment=private in the Basic SKU

alexsevilla 0 Reputation points
2026-09-10T12:26:15.9266667+00:00

We are seeing different behavior between two Azure AI Search services with the same SKU and region.

Both services have:

  • Region: Spain Central
  • SKU: Basic
  • hostingMode: Default
  • computeType: Default
  • 1 replica
  • 1 partition
  • publicNetworkAccess: Disabled
  • A Private Endpoint for the Search service
  • An approved Shared Private Link Resource to an Azure AI Foundry / Azure OpenAI resource
  • Shared Private Link groupId: openai_account
  • A user-assigned managed identity
  • The same indexer / datasource / skillset architecture
  • Skillsets that need to call models hosted in Azure AI Foundry through private connectivity

For this reason, the indexers are configured with:

{
  "parameters": {
    "configuration": {
      "executionEnvironment": "private"
    }
  }
}

The unexpected behavior is the following.

Service A:

  • SKU: Basic
  • Region: Spain Central
  • Created on: 2026-07-30
  • serviceUpgradedAt: 2026-08-08
  • executionEnvironment="private" works correctly
  • New indexers can still be created today with executionEnvironment="private"

Service B:

  • SKU: Basic
  • Region: Spain Central
  • Created on: 2026-09-09
  • serviceUpgradedAt: null

When creating an equivalent indexer on Service B, Azure AI Search returns:

[400 Bad Request]

Setting execution mode of indexer <indexer-name> to 'Private' is unsupported for your search service SKU basic

The REST API version used to create the indexer is:

2026-05-01-preview

This is not an issue with the existing indexer on Service A: we have verified that we can still create completely new resources on Service A today, including:

  • Knowledge Base
  • Index
  • Indexer
  • Data Source
  • Skillset

and the new indexer is successfully created with executionEnvironment="private".

Therefore, this does not appear to be just a recent REST API validation change affecting all Basic services.

The relevant ARM properties of both Search services are effectively the same, except for their creation dates and serviceUpgradedAt value.

My questions are:

  1. Has the behavior or supported feature set of newly provisioned Basic Azure AI Search services changed recently regarding executionEnvironment="private"?
  2. Is executionEnvironment="private" officially supported on Basic services that use Shared Private Link Resources for skillsets calling Azure AI Foundry / Azure OpenAI models?
  3. If this behavior is intentional, what is the minimum SKU currently required for:
    • an indexer with a skillset,
    • executionEnvironment="private",
    • and access to Azure AI Foundry / Azure OpenAI through an approved Shared Private Link Resource?
  4. Is there any supported way to upgrade/migrate a newly created Basic service so that it has the same private indexer execution capability as Service A? I don't want to pay the price difference for S1 just for this feature

The main point we would like to clarify is why two Basic services in the same region, with equivalent configuration, currently behave differently when creating a new private indexer.

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 No comments

1 answer

Sort by: Oldest
  1. AI answer

    2026-09-10T12:26:44.2433333+00:00

    The documented support does not match the behavior seen on Service A.

    1. executionEnvironment="private" is documented as requiring Standard2 or higher. The feature availability table states that the ability to pin all indexer processing to the search clusters allocated to the service requires S2 and higher. The indexer execution environment article also says the multitenant environment can be prevented only on Standard2 or higher services by setting executionEnvironment to the private execution environment.
    2. For private connectivity scenarios, the documentation says that if a private connection is used between an indexer and a data source or other Azure resource, the indexer must run in the private execution environment, and each indexer must have executionEnvironment set to Private.
    3. For the combination requested:
      • indexer with a skillset
      • executionEnvironment="private"
      • outbound private connectivity through shared private link
      the minimum documented SKU is S2. There is also an additional limitation for private endpoints used by indexers with skillsets: outbound private endpoint support for indexers that use skillsets is documented as not available on Free, Basic, S1, or S3 HD.
    4. No supported upgrade or migration path is documented that would make a newly created Basic service gain private indexer execution capability equivalent to Service A. The only documented path is to use a SKU that supports the feature set, which is S2 or higher.
    5. Why the two Basic services behave differently cannot be explained from the documented feature matrix. Based on the published documentation, Service B’s 400 response is consistent with current documented support, while Service A appears to be an exception relative to the documentation.
    6. One more SKU caveat: on S3 HD and Serverless, indexers run only in the multitenant execution environment, so those SKUs are not valid alternatives for executionEnvironment="private".

    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.