File Search in Microsoft Foundry: "The server had an error processing your request."

Question

File Search in Microsoft Foundry: "The server had an error processing your request."

Matt Williams 40 Microsoft Employee

I have an Agent in Microsoft Foundry without a File Search tool. It responds to questions correctly.

When I add the File Search tool (and this is the only change) through the Portal, I see it appear under Tools, it briefly says "Indexing..." and then shows a "vs_..." ID, which I think means it is ready for use.

However, if I now ask it a question that needs the File Search tool, it responds with:

Error The server had an error processing your request. Sorry about that! You can retry your request, or contact us through an Azure support request at: https://go.microsoft.com/fwlink/?linkid=2213926 if you keep seeing this error. (Please include the request ID a2885f2a-cc06-xxxxxxxxxxx in your email.)

In case it's relevant, note that my Microsoft Foundry deployment is on a private VNet, using the bicep template at https://github.com/microsoft-foundry/foundry-samples/tree/main/infrastructure/infrastructure-setup-bicep/15-private-network-standard-agent-setup. The agent is able to access all other resources on my private VNet, so in general this is set up correctly.

Thanks for any help you can provide!

SRILAKSHMI C 18,035 Reputation points Microsoft External Staff Moderator

2026-05-05T14:45:09.8866667+00:00
Hello Matt Williams,

Thanks for reaching out Microsoft Q&A,

From what you’ve described, your agent itself appears healthy, and the issue is occurring specifically when the File Search tool is invoked, which results in the generic 500 error. This typically points to a problem in the retrieval/runtime path rather than the agent configuration itself.

To isolate the issue, could you please check the following:

1. Vector store status

In the Portal: Foundry Project → Agents → Your Agent → Tools → File Search

Ensure the vector store shows “Succeeded” or “Ready” (not still “Indexing”)

If still indexing, wait until it completes fully before testing

2. Agent configuration

Confirm your agent definition (YAML/JSON if applicable) includes file_search tool enabled

Correct vector_store_ids value (matching the vs_... ID shown in the portal)

3. Test vector store endpoint directly From a VM inside the same private VNet, try calling the vector store API directly:

curl -H "Authorization: Bearer <token>" https://<endpoint>/vectorStores/<vs_id>/documents

If this call also returns a 500, it indicates a service-side or networking issue, not agent logic

4. Private networking validation Since your setup is fully private, please double-check:

NSG / UDR rules allow outbound access to required Foundry endpoints

Any required private endpoints are correctly configured

DNS resolution is correctly pointing to private endpoint IPs (via Private DNS Zones or custom DNS)

5. Service health & quotas

Check for any regional issues via Azure Status

Ensure no quota limits (TPM/RPM or resource limits) are being hit

Based on your architecture (private VNet using the Bicep template), this behavior is consistent with a current limitation While File Search indexing may succeed, the query execution path depends on backend services that are not yet fully supported over private networking in all scenarios.

This explains why:

Agent works without File Search

Index appears ready (vs_...)

Queries using File Search fail with 500

As a quick confirmation step:

Temporarily test the same agent with public network access enabled

If it works in that setup, it would confirm the issue is related to private network isolation impacting File Search runtime.

workaround

Use File Search with public access enabled Or continue using the agent without File Search in the private VNet setup

Please refer this

HTTP 500 / 503 / Service Unavailable troubleshooting: https://learn.microsoft.com/azure/ai-services/agents/how-to/tools/bing-grounding?tabs=python&pivots=overview

File Search tool for agents (with troubleshooting): https://learn.microsoft.com/azure/foundry/agents/how-to/tools/file-search?wt.mc_id=knowledgesearch_inproduct_azure-cxp-community-insider#troubleshooting

I Hope this helps. Do let me know if you have any further queries.

Thank you!
Alex Burlachenko 20,665 Reputation points MVP Volunteer Moderator

2026-05-05T14:51:28.7466667+00:00
Matt Williams hi & thx for join me here at Q&A portal,

File Search adds Blob + AI Search dependency, so validate vector store completed + private endpoint DNS + RBAC for Search/Storage .... this smells like File Search dependency path, not the agent itself. File Search is not just a flag on the agent; it uses the connected Azure Blob Storage for files and Azure AI Search for vector store/indexing, and Microsoft docs say those resources are part of the standard agent setup. (learn.microsoft.com) since ur agent works until File Search is added, focus on Blob/Search connectivity + permissions in the private setup. First confirm the vector store is really completed, not just showing a vs_... id; docs say u should wait/poll until vector store status is completed before querying. (learn.microsoft.com) then check that the Foundry agent/project managed identity has correct RBAC on Storage and AI Search, and that private endpoints/DNS exist for both. The private networking setup also requires permissions/role assignment for Azure Cosmos DB, Azure AI Search, and Azure Storage, not only general VNet access. (learn.microsoft.com) practical test: temporarily allow trusted/public access on Search/Storage just to isolate. If File Search starts working, private endpoint/DNS/RBAC is the issue. If it still fails with same request ID, then its likely service-side and support needs that request ID.

rgds, Alex

&

if my answer helps pls accept it.
Matt Williams 40 Reputation points Microsoft Employee

2026-05-06T05:17:11.6566667+00:00
Thank you (and @Alex Burlachenko ) for the suggestions. I've worked through them but unfortunately the issue persists. I’ve confirmed the following.

The vector store is healthy. The portal doesn’t show Succeeded or Ready – it just shows its name. However, I’ve previously seen it temporarily saying “Indexing…”, so I believe that the name alone indicates ready. Further, I can hit the vector store’s endpoint directly (with suitable authentication) and perform searches successfully.

The agent configuration includes file_search (with matching vector store IDs) in both the tools array and tool_resources section.

(We’re using the correct instance of the vector store service. Foundry apparently exposes both global and per-project instances and we are configuring the project-scope one. I created a global-scope vector store and tested with that, but then got a different “vector store not found” error, which confirms that the project-scope instance is correct.)

Both the project and the foundry managed identities have Search Index Data Contributor, Search Service Contributor, Cosmos DB Operator, Storage Blob Data Owner, Storage Blob Data Contributor, and Cognitive Services OpenAI User. (I intend to slim this down once I know what is actually required.)

The Foundry instance is correctly injected on the VNet, as it can reach my other MCP servers, which are private to that VNet.

We have private endpoints for all resources (Foundry, Search, Cosmos, Storage), and private DNS zones attached to the VNet that match these endpoints. (These private endpoints are also working for other services we’re using.)

The NSGs involved between these resources allow all on-VNet traffic through.

I don’t believe I’m hitting any quota limits – I’m definitely not hitting RPM/TPM and would be surprised if I’m hitting any vector store limits, because it’s just me testing this.

I temporarily enabled public network access to all of Foundry, Search, Cosmos and Storage, but the test still failed. (Note that I did not disable the private DNS zones so, for clients on the VNet, the private endpoints would still have been used.)

Is there any way I can get more detail on the “The server had an error processing your request” error, by looking up the request ID in some other diagnostics?

You mentioned a “current limitation” with “query execution path depend[ing] on backend services that are not yet fully supported over private networking”. Is that a known limitation, or are you hypothesizing? If it’s a known limitation, please can you share more details?