Azure AI Foundry Playground shows "No deployment exists" — ML RP data plane returns 403 Forbidden while ARM control plane returns 200 OK

Anonymous
2026-06-11T12:35:02.26+00:00

Problem Summary

The Azure AI Foundry Playground Agents tab shows "No deployment exists" in the model deployment dropdown, even though the Azure OpenAI deployment is correctly provisioned and the Agent Runtime API works perfectly.

Environment:

  • Region: East US 2
  • Azure AI Hub: macrocloud-ai-hub
  • Azure AI Project: macrocloud-agents-project
  • Azure OpenAI Resource: macrocloud-ai-agent-eus2
  • Connection: my_aoai (useWorkspaceManagedIdentity: true)
  • Model Deployment: macrocloud-agent-gpt-41-mini (gpt-4.1-mini, GlobalStandard, provisioningState: Succeeded)

ARM Control Plane — WORKS ✅

GET https://management.azure.com/subscriptions/e7f7c041-f73d-47cd-9e33-02b2c59ef7ec/resourceGroups/MacroCloud-AI-RG/providers/Microsoft.MachineLearningServices/workspaces/macrocloud-agents-project/connections/my_aoai/deployments?api-version=2024-04-01-preview

→ HTTP 200 OK — returns macrocloud-agent-gpt-41-mini (gpt-4.1-mini, provisioningState: Succeeded)

ARM Correlation ID: 6ff761f9-ebb3-4da4-9b3d-3292c015bff0

ML RP Data Plane — FAILS ❌

GET https://eastus2.api.azureml.ms/rp/workspaces/subscriptions/e7f7c041-f73d-47cd-9e33-02b2c59ef7ec/resourceGroups/MacroCloud-AI-RG/providers/Microsoft.MachineLearningServices/workspaces/macrocloud-agents-project/connections/my_aoai/deployments?api-version=2024-04-01

→ HTTP 403 Forbidden — empty response body

This is the endpoint called by the Foundry Playground UI to populate the deployment dropdown.

Root Cause

When the Azure OpenAI resource was recreated, Azure auto-assigned a custom subdomain suffix due to a soft-delete DNS hold:

  • Expected: macrocloud-ai-agent-eus2.openai.azure.com → NXDOMAIN ❌
  • Assigned: macrocloud-ai-agent-eus2-09f85.openai.azure.com → resolves correctly ✅

The connection object correctly stores the assigned endpoint in the target property. However, the ML RP data plane service appears to ignore the target property and reconstructs the endpoint from the resource name — hitting the unresolvable default subdomain and returning 403 Forbidden.

What We Ruled Out

Check Result
Workspace corruption ❌ Ruled out — fresh project has same 403
RBAC missing ❌ Ruled out — all roles assigned correctly
Deployment not provisioned ❌ Ruled out — ARM returns 200 OK
Agent Runtime API ✅ Working — runs complete in 3 seconds

Questions

  1. Does the ML RP data plane (eastus2.api.azureml.ms/rp) ignore the connection target property when resolving the AOAI endpoint?
  2. Is there a way to force the default subdomain (macrocloud-ai-agent-eus2.openai.azure.com) to be registered without the auto-suffix?
  3. Is this a known Azure AI Foundry Preview bug?
Foundry Tools
Foundry Tools

Formerly known as Azure AI Services or Azure Cognitive Services is a unified collection of prebuilt AI capabilities within the Microsoft Foundry platform

0 comments

2 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Thanmayi Godithi 10,820 Reputation points Microsoft External Staff Moderator
    2026-07-03T10:46:20.9233333+00:00

    Hi ,

    Excellent diagnosis — your root cause is essentially right, and it lines up with documented Azure behavior. Two things are interacting:

    1. The AOAI custom subdomain is derived from the resource name (<name>.openai.azure.com), and Entra-ID auth + DNS resolution depend on it.
    2. When you recreated the resource, the original name was still held by a soft-deleted resource's name/DNS reservation (up to 48h if deleted programmatically), so Azure gave you a suffixed subdomain (...-eus2-09f85). The clean default stayed NXDOMAIN.

    ARM reads the deployment straight from the resource record (200 OK), but the Playground's ML RP data-plane call reaches the AOAI account via its canonical, name-derived subdomain — which points at the unresolvable default — so it 403s and the dropdown shows "No deployment exists." That's why the runtime API works but the Playground list doesn't.

    Durable fix — reclaim the clean subdomain:

    1. Purge the soft-deleted AOAI resource holding the name: portal → Azure AI services → Manage deleted resources, or az cognitiveservices account purge --name macrocloud-ai-agent-eus2 --resource-group MacroCloud-AI-RG --location eastus2 (If it was deleted via API, the name can be reserved up to 48h; purging releases it immediately.)
    2. Recreate the AOAI resource with the custom subdomain set to the resource name so you get macrocloud-ai-agent-eus2.openai.azure.com (no suffix). If you use ARM/Bicep/Terraform/CLI, set the custom-subdomain property explicitly. Redeploy gpt-4.1-mini.
    3. Recreate the my_aoai connection against the clean endpoint and confirm its target matches the canonical *.openai.azure.com. Refresh the Playground.

    Non-destructive test first: delete and recreate just the my_aoai connection so its target is re-read, then re-open the model dropdown. Sometimes that re-syncs resolution; if not, do the purge + rename above.

    To your three questions: (1) effectively yes — the data plane resolves by the name-derived subdomain, so a suffixed subdomain that differs from the resource name causes the 403; (2) yes, purge the soft-deleted resource then recreate with subdomain = name; (3) it's a known-behavior interaction rather than a confirmed Preview bug. If it still 403s on a clean, name-matching subdomain, that's worth a support ticket — include your ARM correlation ID (6ff761f9-…) and the apim-request-id from the failing data-plane call.

    Refs:

    Was this answer helpful?

    0 comments

  2. AI answer

    2026-06-11T12:35:17.77+00:00

    The behavior described cannot be confirmed or explained from the available documentation.

    References:

    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.