How to fix Azure Foundry

Question

How to fix Azure Foundry

Jyo 40

User's image

0 comments

Answer accepted by question author

0 additional answers

Your answer

Answer 1

Hi @Jyo

please follow the below steps and give your feedback.

1. Check your network and proxy

Try opening another Foundry section (like Models or Tools) to confirm if the issue is isolated to “Agents.”

2. Clear browser cache and disable blockers

Clear cookies for ai.azure.com and reload.

3. Verify permissions

Foundry requires Log Analytics Reader or Project Contributor roles to view agents.

4. Try a different browser or network

Use Microsoft Edge or Chrome (latest version).

5. Create a new agent manually

you can still click “New agent” to start fresh — Foundry will create a new entry even if the existing ones aren’t visible.

Next diagnostic step

If the error persists, open Developer Tools (F12) → Network tab → reload the page.

Look for failed requests to foundry.build/agents.

Share the error code (e.g., 403, 404, 500) — that will pinpoint whether it’s a permission, API, or network issue.

Thanks.

Answer 2

Allan Solomon Mejia 8,420

Hello @Jyo

Based on the screenshot, Azure Foundry is returning "Error loading your agents. Your request for data was not sent." This typically indicates a connectivity or access issue rather than a problem with the agent itself.

I'd recommend checking the following:

Verify you're using a supported browser (Edge or Chrome) and try an InPrivate/Incognito session to rule out cached data or extensions.
Check whether a corporate proxy, firewall, VPN, or ad blocker is preventing requests to Azure AI Foundry endpoints. Open the browser's Developer Tools (F12) > Network tab and look for failed requests (403, 407, or CORS errors).
Confirm your Azure AI Foundry project is associated with the correct Azure subscription and that your account has sufficient RBAC permissions (for example, Azure AI Developer or Contributor, depending on the operation).
Verify the Azure AI Foundry resource and any dependent Azure AI Services/OpenAI resources are healthy and deployed in a supported region.
If your organization uses Private Link or network isolation, ensure the required endpoints are reachable and DNS resolution is working correctly.
Check the browser console for JavaScript errors and review the Activity Log in the Azure portal for any authorization failures.

To help narrow it down, could you provide:

Is this happening for all projects or just one?
Are you using a corporate network or a personal internet connection?
Do you see any specific HTTP status codes (403, 401, 500, etc.) in the browser's Network tab?
Has this ever worked before, or is this a new deployment?

Those details will help determine whether this is a permission, networking, or service issue.

Please "Accept the Answer" if this information helped you. This will help us and others in the community as well.

Jyo 40 Reputation points

2026-08-06T10:28:01.6066667+00:00
Is this happening for all projects or just one? -All

Are you using a corporate network or a personal internet connection? - Corporate

Do you see any specific HTTP status codes (403, 401, 500, etc.) in the browser's Network tab? - No

Has this ever worked before, or is this a new deployment? - First Time. Our Foundry resources is in Sweden Central where is our other Azure Resources is in North Europe. All public access diabled. Everything should be through Private Endpoint. So there is Vnet Peering for traffic to be routed between zones.
Allan Solomon Mejia 8,420 Reputation points

2026-08-06T19:01:06.1+00:00
Hi @Jyo

Thank you for the additional details.

Since this is affecting all projects, there are no HTTP errors in the browser, and your environment is configured with Private Endpoints only (with public network access disabled), I'd focus on validating the network path between Azure AI Foundry and its dependent resources.

In particular, I'd recommend checking the following:

Verify that the Azure AI Foundry workspace can resolve and reach all dependent resources (Azure AI Services/OpenAI, Storage, Key Vault, etc.) through their Private Endpoints.

Confirm that the required Private DNS Zones are linked to the VNets hosting both the Foundry workspace and the dependent resources, and that DNS resolution returns the private IP addresses.

Ensure the VNet peering is configured to allow traffic in both directions (where required) and that no NSGs, Azure Firewall rules, or UDRs are blocking connectivity.

From a VM in the same VNet, test DNS resolution and connectivity to the private endpoints (for example, using nslookup and Test-NetConnection).

Review the browser's Developer Tools (Network tab) and the Azure Activity Log for any failed backend requests that may not surface as visible HTTP errors in the UI.

Since this is a new deployment, I'd also recommend temporarily enabling public network access (if your organization's security policy allows) as a diagnostic step. If the issue is resolved with public access enabled, that would strongly indicate the problem lies with the Private Link, DNS, or network configuration rather than Azure AI Foundry itself.

Please "Accept the Answer" if this information helped you. This will help us and others in the community as well.
Jyo 40 Reputation points

2026-08-07T10:47:40.59+00:00

We have dev vnet and subnet created in Sweden Central. Sweden central Vnet is peered to North Europe Management Vnet as we want to use our other azure resources from North Europe.

foundry-copilot-architecture.png

See the full architecture. We want to publish agent as copilot agent.

Can you guide me how I can setup Foundry in Sweden Central in steps. So idea is to have as little footprint as possible in sweden central and reuse from North Europe.
Allan Solomon Mejia 8,420 Reputation points

2026-08-07T15:46:22.6066667+00:00
Hi @Jyo

Thanks for sharing the architecture diagram. This makes the scenario much clearer.

Your proposed design is reasonable: keep the Microsoft Foundry / Agent components in Sweden Central and continue using existing services in North Europe wherever supported. However, I would not rely on VNet peering alone to make the Foundry Agent reach those private services.

From the diagram, you currently have:

Microsoft Foundry in Sweden Central

A subnet delegated to Microsoft.App/environments

VNet peering between Sweden Central and North Europe

Existing OpenAI, AI Search, Storage, Key Vault, Cosmos DB, SQL and other services in North Europe

Public access disabled with Private Endpoints for many of those services

For the Foundry Agent workload, I would configure the environment in this order:

1. Keep the Foundry resource/project in Sweden Central

Sweden Central is currently supported for Microsoft Foundry managed virtual network scenarios, so there is no need to move your existing North Europe platform just to host the Agent workload.

2. Enable the appropriate Foundry network isolation

If your requirement is private-only connectivity, use the restrictive networking model such as Allow only approved outbound rather than assuming the Agent will simply route through the Sweden Central VNet and its peering.

Foundry's managed network can create managed private endpoints to dependent Azure resources, including:

Azure AI Search

Azure Storage

Azure Cosmos DB

Azure Key Vault

Microsoft Foundry / AI Services

Azure SQL and several other Azure services

Those managed private endpoints are different from the Private Endpoints already visible in your customer VNet. They are created and managed within the Foundry networking boundary.

3. Create outbound private-endpoint rules to the North Europe resources that the Agent actually needs

For example, if the Copilot Agent needs your existing:

Foundry Agent → Azure AI Search

Foundry Agent → Storage

Foundry Agent → Cosmos DB

then configure Foundry managed-private-endpoint outbound rules for those specific resources rather than duplicating all of them in Sweden Central.

This is where you can keep the Sweden Central footprint relatively small.

4. Don't duplicate everything just because it is cross-region

The services don't necessarily have to be in the same Azure region simply because Foundry is in Sweden Central. The more important questions are whether that specific service/feature supports the connection and whether Foundry can establish the required private endpoint to it.

Your existing North Europe resources can therefore potentially remain where they are.

5. Pay attention particularly to Azure AI Search

If the Agent uses Azure AI Search as a tool and your Search service has public network access disabled, Microsoft currently requires the appropriate private-network Agent architecture. The connection should also use Microsoft Entra managed identity rather than an API key for private VNet access.

6. Configure RBAC for the Foundry managed identity

The Foundry resource's managed identity must have sufficient permissions on the destination resources to establish/approve the managed private endpoint connections. Microsoft specifically documents the Azure AI Enterprise Network Connection Approver role for this purpose.

7. Test each dependency individually

I would start with the minimum Agent:

Foundry Agent (Sweden Central) → Model deployment

Then add:

→ AI Search

→ Storage

→ Cosmos DB

one at a time. This will make it much easier to identify which private dependency is causing the current Foundry UI/Agent problem.

One thing I would not recommend is creating duplicate Storage, Search, Cosmos DB, Key Vault, etc. in Sweden Central before confirming that a regional restriction actually requires it. Your diagram already has a substantial private-services footprint in North Europe, and many of those resources can be targeted through Foundry managed private endpoints.

The key architectural point is therefore:

VNet peering provides connectivity between your customer VNets, but Foundry Agent outbound connectivity should be configured through the Foundry networking model and its approved outbound/private-endpoint rules.

Here are the references:

Microsoft Foundry managed virtual network:

https://learn.microsoft.com/azure/foundry/how-to/managed-virtual-network

Private networking for Foundry Agent Service:

https://learn.microsoft.com/azure/ai-foundry/agents/how-to/virtual-networks

Azure AI Search with Foundry Agents:

https://learn.microsoft.com/azure/foundry/agents/how-to/tools/ai-search

Based on the diagram, I would therefore keep Foundry and the delegated Agent subnet in Sweden Central, retain the existing services in North Europe where supported, and explicitly create the required Foundry private outbound connections to those North Europe resources. That gives you the smallest Sweden Central footprint without unnecessarily duplicating the existing platform.

Please don't forget to "Accept the Answer" if this information helped you. This will help us and others in the community as well.
Jyo 40 Reputation points

2026-08-07T16:06:15.14+00:00

One Basic Question.

To deploy Foundry. I need to create RG in Sweden Central..It is asking for storage account, key valut, azure AI search.

I need help on this "VNet peering provides connectivity between your customer VNets, but Foundry Agent outbound connectivity should be configured through the Foundry networking model and its approved outbound/private-endpoint rules."
Allan Solomon Mejia 8,420 Reputation points

2026-08-07T16:22:45.74+00:00
Hello @Jyo

Thanks for the follow-up. This is a good question, and it's an important distinction.

When you create an Azure AI Foundry project, you're asked to provide (or create):

Azure Storage Account

Azure Key Vault

Azure AI Search (if your solution requires knowledge retrieval/RAG)

These are dependencies of the Foundry project, not resources that must necessarily be newly created in the same region.

The key question is whether your existing North Europe resources are supported for reuse from a Foundry project hosted in Sweden Central.

If cross-region use is supported for your scenario, the recommended approach is:

Deploy the Foundry Hub/Project in Sweden Central.

Reuse your existing Storage, Key Vault, and Azure AI Search in North Europe where supported.

Configure Managed Private Endpoints from the Foundry managed network to those existing resources instead of creating duplicates.

If a particular dependency must reside in the same region (or the portal doesn't allow selecting the existing resource), then you'll need to deploy that specific service in Sweden Central. This depends on the individual Azure service rather than Foundry itself.

Looking at your architecture, I have one question:

When the Foundry deployment wizard asks for Storage, Key Vault, and Azure AI Search, does it allow you to select your existing North Europe resources, or does it only allow resources located in Sweden Central?

That answer will tell us whether you're dealing with:

A regional requirement for that specific Azure service, or

A networking configuration issue after deployment.
Jyo 40 Reputation points

2026-08-07T16:29:53.74+00:00

We are getting the option to choose from North Europe.
Allan Solomon Mejia 8,420 Reputation points

2026-08-07T16:49:22.47+00:00
Thank you, that's an important finding.

Since the deployment wizard allows you to select your existing North Europe Storage Account, Key Vault, and Azure AI Search resources, we can rule out a regional restriction for those dependencies.

That shifts the focus to networking rather than resource placement.

Given your architecture, I would verify the following:

1. Managed Private Endpoints

If your Foundry project is using a managed virtual network, create the required Managed Private Endpoints from the Foundry project to each North Europe resource (Storage, Key Vault, Azure AI Search, Azure AI Services/OpenAI, etc.).

Ensure each private endpoint connection has been approved on the target resource.

2. Private DNS

Confirm the required Private DNS Zones are configured so the Foundry managed network resolves the North Europe services to their private IP addresses, not their public endpoints.

3. Network isolation

Verify that the selected networking mode (for example, Allow only approved outbound) includes outbound rules for every dependency the Copilot Agent uses.

4. Managed Identity permissions

Ensure the Foundry project's managed identity has the required RBAC permissions on the reused North Europe resources (Storage, Key Vault, Azure AI Search, etc.).

Based on what you've shared so far, I don't think you need to duplicate those resources in Sweden Central. Instead, the remaining work is making sure the Foundry managed network can privately access the existing North Europe services.

One final question:

At which step does the deployment fail?

During Foundry project creation?

When creating or publishing the Copilot Agent?

Or only when the Agent tries to access Azure AI Search or another dependency?

That will help identify which dependency is failing and whether the issue is with provisioning or runtime connectivity.
Allan Solomon Mejia 8,420 Reputation points

2026-08-07T18:31:39.8966667+00:00

Hello @Jyo

Let me know if need further assistance, otherwise, please "Accept the Answer". Thank you.
Allan Solomon Mejia 8,420 Reputation points

2026-08-10T17:13:26.44+00:00

Hello @Jyo

VNet peering only provides network connectivity. For Foundry Agent outbound access, configure the required private endpoints (Storage, Key Vault, Azure AI Search) and ensure DNS resolves them correctly.