Share via

Network Error while connecting Azure Foundry resource via Azure Content Understanding Studio

Syed Umair Hasan 155 Reputation points
2026-02-24T19:54:00.4533333+00:00

Hello All,

We are experiencing networking issues while connecting our Azure AI Foundry resource from Azure Content Understanding Studio.

Environment Setup

Public network access is disabled.

Private endpoints are configured for:

cognitiveservices.azure.com

  `openai.azure.com`
  
     `services.ai.azure.com`
     
     Private DNS zones are created and linked.
     

Initial Issue

When attempting to connect the Foundry resource, we first received:

“Public endpoint disabled. Please configure private endpoint.”

We performed nslookup for all configured FQDNs:

*.cognitiveservices.azure.com → resolved to private IP ✔

*.openai.azure.com → resolved to private IP ✔

*.services.ai.azure.com → resolved to a public IP ❌

We identified that the privatelink.services.ai.azure.com private DNS zone was not linked to the VNet. After adding the virtual network link, DNS now resolves correctly to the private IP.

Current Issue

Although DNS resolution is now correct for all endpoints, we are encountering a new generic networking error in Content Understanding Studio. The error message does not provide additional diagnostic details, and we are unable to proceed.Hello All,

We are experiencing networking issues while connecting our Azure AI Foundry resource from Azure Content Understanding Studio.

Environment Setup

Public network access is disabled.

Private endpoints are configured for:

cognitiveservices.azure.com

  `openai.azure.com`
  
     `services.ai.azure.com`
     
     Private DNS zones are created and linked.
     

Initial Issue

When attempting to connect the Foundry resource, we received:

“Public endpoint disabled. Please configure private endpoint.”

User's image

We performed nslookup for all configured FQDNs:

  • *.cognitiveservices.azure.com → resolved to private IP ✔
  • *.openai.azure.com → resolved to private IP ✔
  • *.services.ai.azure.com → resolved to a public IP ❌

We identified that the privatelink.services.ai.azure.com private DNS zone was not linked to the VNet. After adding the virtual network link, DNS now resolves correctly to the private IP.

Current Issue

Although DNS resolution is now correct for all endpoints, we are encountering a new generic networking error in Content Understanding Studio. The error message does not provide additional diagnostic details, and we are unable to proceed.

User's image

User's image

Kindly provide resolution ASAP.

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

Answer accepted by question author

Amit Tyagi 135 Reputation points
2026-02-25T02:02:14.1066667+00:00

Hi,

Since DNS now resolves to private IPs, your private endpoint and DNS configuration are likely correct.

In this setup, the most common cause of a generic “networking error” is the client access path.

When public network access is disabled, the resource is reachable only from:

  • A VM inside the same VNet

A peered VNet

A machine connected via VPN/ExpressRoute

If Azure Content Understanding Studio (or your browser/client) is running outside the VNet, traffic will not reach the private endpoint — even if client ID / secret are valid.

I experienced a very similar scenario while working with a Launchpad subscription demo environment. Private endpoints were correctly configured and DNS resolved properly, but the service was accessible only from the provisioned VMs inside the same VNet. External access failed with a generic networking error despite correct credentials. The root cause was network isolation, not authentication.

You can validate quickly from a VM inside the VNet:

nslookup <resource-name>.services.ai.azure.com

Expected:

Resolves to private IP

TcpTestSucceeded : True

If this works internally but not externally, the issue is network reachability.

Also verify:

Private endpoint connection status = Approved

NSG allows outbound 443

Browser DNS over HTTPS is not bypassing VNet DNS

With private endpoints, network reachability is validated before authentication — so credential errors won’t appear if traffic cannot reach the resource.

Hope this helps.

Was this answer helpful?


0 additional answers

Sort by: Most 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.