Existing Azure OpenAI service not appearing in dropdown when configuring AI Search skillset ("No access to this subscription, or no Azure OpenAI service available under it.")

Question

Existing Azure OpenAI service not appearing in dropdown when configuring AI Search skillset ("No access to this subscription, or no Azure OpenAI service available under it.")

Seetha Ram 20

I am currently trying to configure an Index, Indexer, and Skillset (with multimodal support) in Azure AI Search using the Import Data wizard. During the setup process, I need to connect my existing Azure OpenAI resource. There is also a model deployed. The AI Search service and the Azure OpenAI resources are created in the same region.

However, when I try to select my Azure OpenAI service from the dropdown, it is greyed out, and I receive the following error message beneath the Subscription dropdown:

"No access to this subscription, or no Azure OpenAI service available under it."

Here are the details of my environment:

I am using a Pay-As-You-Go subscription.
I have already created an Azure OpenAI service and deployed models within this exact same subscription.
I am the Owner/Contributor on the subscription and have the necessary Cognitive Services roles.
Both the Azure AI Search service and the Azure OpenAI service are active.

Why is the wizard failing to detect my existing Azure OpenAI resource, and how can I resolve this so I can complete my skillset configuration? Could this be related to region mismatch, RBAC propagation delays, or specific network/firewall settings?

0 comments

Answer accepted by question author

Venkatesan S 10,830 Microsoft External Staff Moderator

Hi @Seetha Ram ,

Thanks for reaching out in Microsoft Q&A forum,

Based on the information you've shared, your Azure OpenAI resource should normally appear in the Import Data wizard if all prerequisites are met. The error message:

"No access to this subscription, or no Azure OpenAI service available under it."

typically indicates that the Azure portal is unable to discover a compatible Azure OpenAI resource for the selected Azure AI Search service. This can occur due to resource compatibility requirements, permission propagation, networking restrictions, or a portal discovery issue.

To help narrow down the cause, please review the following:

Verify the Azure OpenAI resource type Ensure that you are using an Azure OpenAI resource (Microsoft.CognitiveServices/accounts with Kind = OpenAI) and not an Azure AI Services multi-service resource.
Confirm region compatibility Although you mentioned that both Azure AI Search and Azure OpenAI are deployed in the same region, please verify the exact Azure region names. The Import Data wizard only lists Azure OpenAI resources that are supported for the selected Azure AI Search scenario, and unsupported region combinations may prevent the resource from appearing.
Check the model deployment Verify that your Azure OpenAI resource has a supported model deployment, that the deployment completed successfully, and that it is available in the same Azure OpenAI resource you are trying to select.
Review permissions and RBAC Since you are the Owner/Contributor, you should generally have the required Azure Resource Manager permissions. However, if role assignments were recently added or modified, it may take some time for them to propagate. Signing out of the Azure portal and signing back in can also help refresh cached credentials.
Review networking configuration If your Azure OpenAI resource is configured with Private Endpoints, disabled public network access, or firewall restrictions, verify that the networking configuration supports Azure AI Search connectivity. While these settings are more commonly associated with runtime connectivity, they can also affect certain portal validation scenarios.
Verify subscription and tenant Ensure that both the Azure AI Search service and the Azure OpenAI resource belong to the same Azure subscription and Microsoft Entra tenant, and that the correct directory is selected in the Azure portal.
Try a different browser or an InPrivate session Occasionally, cached portal data can cause resource discovery issues. Testing in an InPrivate/Incognito browser session or using a different browser can help rule out a portal caching issue.

If all of the above checks are confirmed and the Azure OpenAI resource still does not appear in the dropdown, you can also try creating the skillset using Azure Resource Manager (ARM), REST API, or Azure CLI by explicitly referencing the Azure OpenAI resource. This helps determine whether the issue is limited to the portal experience or if there is an underlying service validation issue.

Official documentation links:

Kindly let us know if the above helps or you need further assistance on this issue.

Please do not forget to and “up-vote” wherever the information provided helps you, this can be beneficial to other community members.

Seetha Ram 20 Reputation points

2026-07-20T06:18:02.0933333+00:00

Hi @Venkatesan S
Thank you for the suggestions! I've gone through all the recommended checkpoints, but unfortunately, the Azure OpenAI resources are still not appearing in the dropdown within the portal UI.

There is only one subscription present in the portal; there is no scope for confusion. In fact, the same setup used to work.

Interestingly, I did manage to work around this by provisioning the Azure AI Search skillset — configured with Azure OpenAI — directly via the REST API, and it completed successfully.

This discrepancy between the portal experience and the REST API behavior makes me wonder if this could be a portal rendering issue or a regional propagation delay, rather than an actual resource configuration or permission problem. The underlying resources and their connectivity appear to be functioning correctly when accessed programmatically.

Any insights on what might be causing this UI inconsistency would be greatly appreciated!
Seetha Ram 20 Reputation points

2026-07-20T06:22:09.44+00:00
Venkatesan S 10,830 Reputation points Microsoft External Staff Moderator

2026-07-22T09:25:23.4066667+00:00

Hi @Seetha Ram ,

Thank you for your patience.

I will check with the internal team and provide you with an update as soon as possible.
Venkatesan S 10,830 Reputation points Microsoft External Staff Moderator

2026-07-22T14:34:30.8633333+00:00

Hi @Seetha Ram

Thank you for the detailed update and for sharing your observations.

I'm glad to hear that you were able to successfully create the Azure AI Search skillset using the REST API. As you noted, this confirmed that the underlying Azure OpenAI resource, connectivity, and permissions were functioning correctly, and that the behavior was limited to the Azure portal experience.

I'm pleased to let you know that the portal issue has now been addressed. You should now be able to see the Azure OpenAI resources in the portal as expected when configuring the Import Data workflow.

Could you please refresh the Azure portal and verify whether the Azure OpenAI resource now appears in the dropdown? If so, the issue should be resolved, and you should be able to continue using the portal without relying on the REST API workaround.

Please let me know the outcome. If everything is working as expected and you have no further questions.
Please do not forget to and “up-vote” wherever the information provided helps you, this can be beneficial to other community members.
Seetha Ram 20 Reputation points

2026-07-23T07:08:26.58+00:00
Hi @Venkatesan S

I have checked it, and the resources are being loaded into the dropdown for selection.

I recently noticed the banner on the Azure OpenAI on Your Data page and am planning to migrate my existing RAG implementation from the legacy Azure OpenAI APIs (Old Foundry portal) to Microsoft Foundry.

My current implementation uses the Chat Completions API with Azure OpenAI and returns grounded responses with citations. Now, I want to move to the Microsoft Foundry ecosystem while continuing to build a document-grounded RAG solution that returns citations from documents stored in an Azure Blob Storage container.

After going through the documentation, I found what appear to be the following implementation paths:

Using the model deployment endpoint (REST API): Use the deployment endpoint URL and API key of the deployed model, similar to the legacy Chat Completions API, where the complete conversation history is sent in the request, along with the configured data source for grounding.

Using Microsoft Foundry Agents: Requires a service principal with the required RBAC permissions. Within this approach, I found two options for grounding the agent:

Agentic Retrieval, using a Knowledge Resource backed by an Azure AI Search knowledge base.

Azure AI Search as an agent tool, by registering the AI Search service as a connector within Microsoft Foundry and allowing the agent to query it directly.

My goal is to build a smooth and maintainable RAG solution grounded in documents stored in Azure Blob Storage while continuing to receive accurate citations in the generated responses. And the path that accepts and handles any model deployment in the same way (I want an architecture that eliminates the differences in the model request body, i.e., some models support max_tokens, while some support max_completion_tokens).

Are these the primary approaches available today, or have I missed any recommended architecture or implementation path? If you were starting a new RAG application on Microsoft Foundry today, which approach would you recommend and why?

Thanks again for your response.
Venkatesan S 10,830 Reputation points Microsoft External Staff Moderator

2026-07-23T07:40:45.3766667+00:00
Hi @Seetha Ram ,

Thank you for confirming that the Azure OpenAI resources are now loading correctly in the dropdown. I'm glad to hear that the portal behavior has been resolved and that you're able to continue using the Import Data experience as expected

Regarding your migration plans, your understanding of the available approaches is generally correct.

Based on the current Microsoft guidance and the retirement notice shown in the Azure OpenAI On Your Data experience, there are effectively two strategic paths for building document-grounded RAG solutions going forward:

Option 1: Model Deployment Endpoint (Application-Managed RAG)

In this approach, your application continues to orchestrate the RAG workflow directly:

Azure AI Search performs retrieval against documents stored in Azure Blob Storage and indexed into Azure AI Search.

Your application sends retrieved content to the deployed model endpoint.

Conversation history, prompt construction, grounding logic, citation formatting, and orchestration remain under application control.

This approach offers:

Maximum flexibility and customization.

Full control over prompts, retrieval strategy, chunking, ranking, and citation formatting.

Easier migration from existing Chat Completions-based implementations.

However, your application remains responsible for managing the complete RAG orchestration layer.

Option 2: Microsoft Foundry Agents

This is the strategic direction Microsoft is currently investing in for new AI application development.

Within Foundry Agents, the two approaches you identified are the primary patterns:

A. Agentic Retrieval with a Knowledge Resource

Documents are indexed into Azure AI Search.

Azure AI Search knowledge resources are connected to the agent.

The agent performs retrieval, grounding, and response generation.

Citations and source references are provided as part of the agent response experience.

This closely aligns with Microsoft's recommended migration path from Azure OpenAI On Your Data toward Foundry Agent Service.

B. Azure AI Search as an Agent Tool

Azure AI Search is registered as a tool/connector available to the agent.

The agent decides when and how to use the search capability.

Useful for more complex agentic workflows involving multiple tools, reasoning steps, or external systems.

This approach is typically better suited when the agent must combine search results with additional actions, APIs, business systems, or tool invocations.

Kindly let us know if the above helps or you need further assistance on this issue.

Please do not forget to and “up-vote” wherever the information provided helps you, this can be beneficial to other community members.

2 additional answers

Your answer

Seetha Ram 20 Reputation points

2026-07-20T06:18:02.0933333+00:00

Hi @Venkatesan S
Thank you for the suggestions! I've gone through all the recommended checkpoints, but unfortunately, the Azure OpenAI resources are still not appearing in the dropdown within the portal UI.

There is only one subscription present in the portal; there is no scope for confusion. In fact, the same setup used to work.

Interestingly, I did manage to work around this by provisioning the Azure AI Search skillset — configured with Azure OpenAI — directly via the REST API, and it completed successfully.

This discrepancy between the portal experience and the REST API behavior makes me wonder if this could be a portal rendering issue or a regional propagation delay, rather than an actual resource configuration or permission problem. The underlying resources and their connectivity appear to be functioning correctly when accessed programmatically.

Any insights on what might be causing this UI inconsistency would be greatly appreciated!
Seetha Ram 20 Reputation points

2026-07-20T06:22:09.44+00:00
Venkatesan S 10,830 Reputation points Microsoft External Staff Moderator

2026-07-22T09:25:23.4066667+00:00

Hi @Seetha Ram ,

Thank you for your patience.

I will check with the internal team and provide you with an update as soon as possible.
Venkatesan S 10,830 Reputation points Microsoft External Staff Moderator

2026-07-22T14:34:30.8633333+00:00

Hi @Seetha Ram

Thank you for the detailed update and for sharing your observations.

I'm glad to hear that you were able to successfully create the Azure AI Search skillset using the REST API. As you noted, this confirmed that the underlying Azure OpenAI resource, connectivity, and permissions were functioning correctly, and that the behavior was limited to the Azure portal experience.

I'm pleased to let you know that the portal issue has now been addressed. You should now be able to see the Azure OpenAI resources in the portal as expected when configuring the Import Data workflow.

Could you please refresh the Azure portal and verify whether the Azure OpenAI resource now appears in the dropdown? If so, the issue should be resolved, and you should be able to continue using the portal without relying on the REST API workaround.

Please let me know the outcome. If everything is working as expected and you have no further questions.
Please do not forget to and “up-vote” wherever the information provided helps you, this can be beneficial to other community members.

Answer 1

Welcome to Microsoft Q&A

Hello @Seetha Ram I hope you are doing well.

The error:

"No access to this subscription, or no Azure OpenAI service available under it."

Usually indicates that the Import Data wizard is unable to enumerate a compatible Azure OpenAI resource. Since you've confirmed that the Azure OpenAI resource already exists, the issue is commonly related to one of the following:

Check this first :

Resource type
- Ensure your resource is an Azure OpenAI resource (Azure AI Foundry/OpenAI) and not a multi-service Azure AI Services resource.
1. Region compatibility
  - Although you mentioned both services are in the same region, verify that the selected Azure OpenAI model and the Azure AI Search service support the integrated vectorization/scillset scenario in that region.
  1. RBAC permissions
    - Being Owner on the subscription is generally sufficient, but if permissions were recently assigned, allow some time for RBAC propagation and sign out/in to the Azure portal.
Network restrictions
- If your Azure OpenAI resource has Public network access disabled, uses Private Endpoints, or has firewall restrictions, the wizard may not be able to discover it. Temporarily allowing public access (or enabling trusted services, if appropriate) can help determine whether networking is the cause.
1. Subscription and tenant
  - Confirm that both the Azure AI Search service and Azure OpenAI resource are in the same Azure subscription and Microsoft Entra tenant currently selected in the portal.

This will help narrow down the root cause further.

References

Azure AI Search + Azure OpenAI integration: https://learn.microsoft.com/azure/search/cognitive-search-skill-azure-openai
Integrated vectorization in Azure AI Search: https://learn.microsoft.com/azure/search/vector-search-integrated-vectorization
Azure OpenAI RBAC: https://learn.microsoft.com/azure/ai-foundry/openai/how-to/role-based-access-control

If my answer helped you, please consider marking it as accepted. This helps others in the community find similar solutions.

Jose Benjamin Solis Nolasco 12,361 Reputation points Volunteer Moderator

2026-07-18T02:17:00.2833333+00:00

@Seetha Ram Just following up, Do you need more guidance or assistance ?

If all your concerns have been resolved, I would greatly appreciate it if you could mark the answer as "Accepted." This helps both us and others in the community.

Answer 2

The most likely causes are unsupported resource/model combinations in the wizard, region/support limitations, or the wizard not being able to enumerate a usable Azure OpenAI resource for the scenario.

What is supported in the wizard for multimodal/vector scenarios:

Use a supported Azure OpenAI resource type For the portal quickstart, Azure OpenAI resources created in the Microsoft Foundry portal aren’t supported for this scenario. The supported option is an Azure OpenAI resource created in the Azure portal.
Verify the resource has a supported endpoint shape The Azure OpenAI resource must have a custom subdomain endpoint such as https://<name>.openai.azure.com.
Verify the deployed model is one the wizard supports For embeddings, supported models listed for this scenario include:
- text-embedding-ada-002
- text-embedding-3-small
- text-embedding-3-large
Check region support For semantic ranker and related search features, region availability matters. If the region used by the resources isn’t supported for the feature set, the wizard might not surface the resource as expected.
Check whether the wizard scenario itself supports the provider/model combination A Microsoft Q&A answer for a similar issue states that the wizard requires supported OpenAI resources and supported models. If the resource contains the model but still doesn’t appear, using SDK or REST API is a valid path instead of the portal wizard.
If using Azure OpenAI On Your Data role-based access patterns, confirm role assignments are correct For Search-to-OpenAI access, the documented role is Cognitive Services OpenAI Contributor assigned to Azure AI Search on the Azure OpenAI resource. In a related resolved case, the search service managed identity had been added to the wrong Azure OpenAI resource, which caused skillset creation failure.
If storage is involved, check access/networking Documented troubleshooting for ingestion failures shows that authorization problems can occur when the storage account isn’t accessible with the provided credentials or is hidden behind a private endpoint without corresponding configuration. That does not directly explain a greyed-out Azure OpenAI dropdown, but it is relevant if the wizard proceeds and later fails.

What to do next:

Confirm the Azure OpenAI resource was created in the Azure portal, not only in Microsoft Foundry.
Confirm its endpoint uses the custom subdomain format.
Confirm the deployment uses a supported embedding model for the wizard.
Confirm the region is supported for the search features being configured.
Verify the Azure AI Search managed identity is assigned on the correct Azure OpenAI resource with the documented role.
If the resource still does not appear in the dropdown, bypass the wizard and create the skillset/indexer using SDK or REST API.

On the specific causes mentioned:

Region mismatch/support limitation: supported by the documentation as a real factor.
RBAC propagation delay: not explicitly documented here as the cause of this dropdown behavior.
Network/firewall settings: documented as a cause for later authorization/ingestion failures, especially with inaccessible storage or private endpoints.