Service administration for Azure AI Search in the Azure portal

In Azure AI Search, the Azure portal supports a broad range of administrative and content management operations so that you don't have to write code unless you want automation.

Each search service is managed as a standalone resource. Your role assignment determines what operations are exposed in the portal.

Portal and administrator permissions

Portal access is through role assignments. By default, all search services start with at least one Owner. Owners, service administrators, and co-administrators have permission to create other administrators and other role assignments. They have full access to all portal pages and operations.

Contributors and Search Service Contributors have the same access as Owner, minus the ability to assign roles.

Readers have access to service information in the Essentials section and in the Monitoring tab. Access is limited. A reader can get basic information about a search service, but not enough to set up a connection or confirm the existence of objects on the service.

For data plane tasks, such as creating and configuring indexes and indexers: on a default system, the portal attempts admin API keys first, even if there are role assignments. If keys are disabled, here's the portal experience for the following roles:

  • Search Index Data Contributor can see the list of indexers, and access an individual one to see its historical runs and status, but cannot run, reset, create, update, or delete it.

  • A Search Index Data Reader can query the indexes.

In short, if you want unrestricted access to portal features, including the ability to run the Import data wizards, you should have Contributor or Search Servicer Contributor permissions.

Tip

By default, any owner or administrator can create or delete services. To prevent accidental deletions, you can lock resources.

Azure portal at a glance

The overview page is the "home" page of each service. In the following screenshot, the red boxes indicate tasks, tools, and tiles that you might use often, especially if you're new to the service.

Portal pages for a search service

Area Description
1 A command bar at the top of the page includes Import data wizard and Search explorer, used for prototyping and exploration.
2 The Essentials section lists service properties, such as the service endpoint, service tier, and replica and partition counts.
3 Tabbed pages in the center provide quick access to usage statistics and service health metrics.
4 Navigation links to existing indexes, indexers, data sources, and skillsets.

You can't change the search service name, subscription, resource group, region (location), or tier. Switching tiers requires creating a new service or filing a support ticket to request a tier upgrade, which is only supported for Basic and higher.

Day-one management checklist

On a new search service, we recommend these configuration tasks.

Check capacity and understand billing

By default, a search service is created in a minimum configuration of one replica and partition each. You can add capacity by adding replicas and partitions, but we recommend waiting until volumes require it. Many customers run production workloads on the minimum configuration.

Some features add to the cost of running the service:

Configure network security

By default, a search service accepts authenticated and authorized requests over public internet connections. Network security restricts access through firewall rules, or by disabling public connections and allowing requests only from Azure virtual networks.

Security in Azure AI Search explains inbound and outbound calls in Azure AI Search.

Enable diagnostic logging

Enable diagnostic logging to track user activity. If you skip this step, you still get activity logs and platform metrics automatically, but if you want index and query usage information, you should enable diagnostic logging and choose a destination for logged operations.

We recommend Log Analytics Workspace for durable storage so that you can run system queries in the portal.

Internally, Microsoft collects telemetry data about your service and the platform. It's stored internally in Microsoft data centers and made globally available to Microsoft support engineers when you open a support ticket.

Monitoring data Retention
Activity logs 90 days on a rolling schedule
Platform metrics 93 days on a rolling schedule, except that portal visualization is limited to a 30 day window
Resource logs User-managed
Telemetry One and a half years

Note

See the "Data residency" section of the security overview article for more information about data location and privacy.

Configure user access

Initially, only an owner has access to search service information and operations. Assign roles to extend access, or provide users with a search endpoint with an API key.

A search service is always created with API keys. An admin API key grants read-write access to all data plane operations. You can't delete admin API keys but you can disable API keys if you want all users to access data plane operations through role assignments.

Provide connection information to developers

Developers need the following information to connect to Azure AI Search:

  • An endpoint or URL, provided on the Overview page.
  • An API key from the Keys page, or a role assignment (contributor is recommended).

We recommend portal access for the following wizards and tools: Import data wizard, Import and vectorize data, Search explorer. Recall that a user must be a contributor or above to run the import wizards.

Next steps

Programmatic support for service administration can be found in the following APIs and modules:

You can also use the management client libraries in the Azure SDKs for .NET, Python, Java, and JavaScript.

There's feature parity across all modalities and languages, except for preview management features. As a general rule, preview management features are released through the Management REST API first.