Share via

Facing error with Microsoft Foundry: Standard Agent Setup with E2E Network Isolation template is not working properly

Ojas Chopade (LTIMINDTREE LIMITED) 40 Reputation points Microsoft External Staff
2026-06-15T15:19:50.73+00:00

When trying to deploy Foundry agent through template present on github "Microsoft Foundry: Standard Agent Setup with E2E Network Isolation template", private endpoint creation fails with error "vnet not found" whereas the vnet is present and is visible on portal. Please suggest if there is any issue with template.Screenshot 2026-06-15 074936

Screenshot 2026-06-15 074707

Foundry Agent Service
Foundry Agent Service

A fully managed platform in Microsoft Foundry for hosting, scaling, and securing AI agents built with any supported framework or model


3 answers

Sort by: Most helpful
  1. Karnam Venkata Rajeswari 3,675 Reputation points Microsoft External Staff Moderator
    2026-06-15T15:43:54.32+00:00

    Hello @Ojas Chopade (LTIMINDTREE LIMITED) ,

    Welcome to Microsoft Q&A .Thank you for reaching out to us.

    The observed behavior indicates a reference resolution issue rather than an actual VNet absence, most likely caused by parameter or scope mismatch.

    From the information provided, the virtual network is clearly present and accessible in the portal. At the same time, supporting resources such as virtual network links and private DNS zones have been successfully created. This combination strongly indicates that the failure is not due to a missing virtual network, but rather due to the deployment process being unable to resolve the virtual network reference correctly during private endpoint creation.

    The error “virtualNetworks … not found” typically occurs when the template references a virtual network using parameters that do not exactly match the resource at deployment time. This includes mismatches in identifiers, scope, or expected format.

    Please check if the following steps help-

    1. Validating template inputs Ensure that all networking parameters precisely match the actual resources:
      • Subscription ID
      • Resource Group name
      • Virtual Network name or full Resource ID
      • Subnet name
      If the template expects a resource ID, it needs to follow this format:
         /subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.Network/virtualNetworks/<vnet-name>
      
    2. Confirming region alignment For network-isolated agent deployments:
      • The Foundry resource and the virtual network must be deployed in the same Azure region
      A region mismatch can cause failures specifically during private endpoint provisioning.
    3. Verifying Subnet Configuration Ensure that the required subnets exist and meet configuration expectations: Agent Subnet
      1. Delegated to Microsoft.App/environments
      2. Minimum size of /27
      3. Dedicated for agent use
      Private Endpoint Subnet
      1. Present in the same VNet
      2. Matches the name used in deployment parameters
    4. Checking deployment scope Please confirm that:
      • Deployment is executed in the correct subscription
      • Resource group matches the location of the VNet
      • All referenced resources exist within the intended scope
    5. Validating permissions Ensure sufficient access is available for networking operations:
      1. Network Contributor role on the virtual network
      2. Additional permissions if cross-subscription or shared-network deployment is involved
    6. Reviewing deployment operations To identify the exact mismatch:
      1. Navigate to: Resource Group > Deployments > Failed Deployment > Operations
      2. Review the failed private endpoint step
      3. Capture:
        • Full error details
        • Resource ID being referenced
        • Parameter values used
        This view typically reveals the exact reference mismatch.

    After aligning the configuration and redeploying, the issue should be resolved.

    The following references might be helpful , please check them out

    Please let us know if the response was helpful

     

    Thank you

    Was this answer helpful?

    1 person found this answer helpful.
    0 comments No comments

  2. Ojas Chopade (V-OCHOPADE) 0 Reputation points
    2026-06-16T09:59:06.5266667+00:00

    Resource group and vnet was in different region causing the issue. Thank you for your suggestion! The deployment succeeded now! :)

    Was this answer helpful?

    0 comments No comments

  3. AI answer

    2026-06-15T15:20:15.46+00:00

    The error message indicates that the private endpoint deployment cannot find the virtual network resource it is targeting, even though the VNet exists in the portal. In the Foundry network‑isolated templates this typically comes from how the VNet and subnet are referenced, and from required permissions.

    Use the following checks that align with the documented requirements for network‑secured Foundry/Agent setups:

    1. Verify the VNet and subnet used for private endpoints are in the same subscription and resource group that the template expects. If the template parameter for VNet name, resource group, or subscription does not exactly match the existing VNet, the deployment will fail with vnet not found.
    2. Confirm the VNet and subnet are in a valid private address space and meet the size/delegation requirements used by the Foundry templates:
      • VNet address space must be RFC1918 private space: 10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16. If a different range is used, deployment can fail with network‑related errors.
      • The subnet delegated for Agents must be /27 or larger and delegated to Microsoft.App/environments.
    3. Ensure the account running the deployment has the required roles on the VNet and subnet:
      • Network Contributor on the VNet where private endpoints are created.
      • If using cross‑tenant or cross‑subscription networking, confirm the role assignment on the remote VNet is in place as shown in the documented az role assignment create example.
    4. If the template is creating both the VNet and the private endpoints in a single deployment, confirm that the VNet resource name used by the private endpoint resources exactly matches the VNet resource name defined earlier in the template (case‑sensitive) and that there is no typo or mismatch between parameter values and resource names.
    5. After correcting any name, scope, or permission issues, redeploy the template. If deployment still fails with a generic capability host or network error after these checks, follow the guidance to open a support request so the setup can be investigated, as recommended for terminal provisioning failures in secured Agent deployments.

    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.