Add search subnet configuration and update metadata date

[mukesh-dua]

PR Checklist

Check these items before submitting a PR...

Contribution Guide

Best Practice Guide

• - Please check this box once you've submitted the PR if you've read through the Contribution Guide and best practices checklist.

Changelog

Add search subnet configuration and update metadata date

[mukesh-dua]

#sign-off

[ouldsid]

/validate

[mukesh-dua]

@ouldsid can you please help to merge this PR pls. In the failed check, its complaining about gpt-4.1-mini token limits issue, which is out of our control and for the other issue with metadata.json file, I don't see usage of string deployments in it.

[alex-frankel]

Hi @mukesh-dua, thanks for your contribution. Two items needed before this can merge:

1. Rebase against master. PR Update Discovery chat model default to gpt-5.2 #14701 just landed and bumped the Discovery chat model defaults to gpt-5.2 in main.bicep. Your branch was based before that, so a rebase will preserve the new defaults — please don't revert them.

2. Populate testResult in metadata.json. The current value is "N/A", but the contribution guide now requires a testResult.deployments block with real correlationId and deploymentName from an actual Azure deployment. See the contribution guide for the format and how to capture deployment IDs from Azure CLI / PowerShell / portal.

Once both are in, we'll get this merged.

[mukesh-dua]

@alex-frankel changes made. Please help with merge to main

[mukesh-dua]

#sign-off

[alex-frankel]

/verify

[alex-frankel]

/validate

[github-actions]

🤖 Quickstart Sample Summary

Sample Summary

• This sample deploys the full Microsoft Discovery infrastructure stack, including networking, identity, storage, supercomputer compute resources, workspace, and projects.
• It provisions a Virtual Network with multiple subnets (including a newly added search subnet), a User-Assigned Managed Identity, Storage Account with containers, a Supercomputer resource with a Node Pool, a Workspace with a Chat Model Deployment, and associated projects.
• Deployment can be done via ARM templates (azuredeploy.json) or Bicep (main.bicep) specifying parameters such as location, resource names, and subnet address prefixes.

Resources Deployed

• Microsoft.Network/virtualNetworks (in azuredeploy.json): Defines the main Virtual Network with several subnets, including the newly added searchSubnet with address prefix parameterized by searchSubnetPrefix.
• Microsoft.Network/virtualNetworks/subnets (in azuredeploy.json): Defines multiple subnets such as aksSubnet, supercomputerNodepoolSubnet, workspaceSubnet, privateEndpointSubnet, agentSubnet, and the added searchSubnet with service delegation for Microsoft.App/environments.
• Microsoft.ManagedIdentity/userAssignedIdentities (referenced in templates): A User-Assigned Managed Identity for resource authentication.
• Microsoft.Storage/storageAccounts (in Bicep and JSON): Storage Account used for data storage with associated blob containers.
• Microsoft.Storage/storageAccounts/blobServices/containers: Blob containers within the Storage Account for Discovery outputs.
• Microsoft.Discovery/supercomputers (in azuredeploy.json and Bicep): Deploys a Supercomputer resource representing compute infrastructure, uses the 2026-02-01-preview API version.
• Microsoft.Discovery/supercomputers/nodePools: Node Pool resource as part of the Supercomputer.
• Microsoft.Discovery/workspaces: Workspace resource for Discovery usage.
• Microsoft.Discovery/workspaces/chatModelDeployments: Chat Model Deployment under Workspace.
• Microsoft.Discovery/workspaces/projects: Project resource under the Workspace.

Security Findings

• High severity:
  • AZR-000202 (Template Analyzer): Storage accounts accept connections from any network by default. It is recommended to change default network access rules to deny by default and explicitly allow trusted networks.
  • CKV_AZURE_35 (Checkov): Ensure default network access for Storage Accounts is set to deny.
  • CKV_AZURE_36 (Checkov): Ensure 'Trusted Microsoft Services' is enabled for Storage Account access.
• Medium severity:
  • AC_AZURE_0366 (Terrascan): Anonymous, public read access to storage containers can be enabled, which is only recommended if necessary.
• Low severity:
  • CKV_AZURE_43 (Checkov): Ensure Storage Accounts adhere to naming rules.
  • CKV_AZURE_206 (Checkov): Ensure Storage Accounts use replication.
• General note: The templates do not currently restrict default storage account network access, which could expose data; this is a potential security concern to be addressed.

Key Parameters

• location: Azure region where all resources are deployed; valid values are eastus, swedencentral, or uksouth.
• supercomputerName: Name for the Supercomputer resource; must be 3-24 alphanumeric characters or hyphens.
• nodePoolName: Name of the Node Pool under Supercomputer; must be 1-12 lowercase alphanumeric characters starting with a letter.
• searchSubnetPrefix: Address prefix for the newly added Search subnet (default 10.0.6.0/24).
• storageAccountName: Globally unique name for the Azure Storage Account; must be 3-24 lowercase alphanumeric characters.

Notes for Reviewers

• The update adds a new searchSubnet subnet to the Virtual Network with proper service delegation to Microsoft.App/environments.
• Storage accounts allow unrestricted network access by default; it is recommended to update the template to restrict this and explicitly allow trusted networks.
• No indication of hardcoded secrets found in templates.
• Metadata date was updated to 2026-05-05 in metadata.json.
• Documentation and parameters file were updated accordingly.
• Sample uses a preview API for several Microsoft.Discovery resource types.

Files Touched

• azuredeploy.json (main ARM template) — added search subnet and tags.
• azuredeploy.parameters.json — added parameter for searchSubnetPrefix.
• main.bicep — verified core parameter and resource declarations.
• metadata.json — updated metadata date to 2026-05-05.

---

Generated by the quickstart summarizer agent (v2 — agentic + MSDO security) · triggered by /validate

[alex-frankel]

Hi @mukesh-dua, the deployment validation just ran and reported "No ADX record found" for correlationId=9f1d27b8-c74e-482a-b9a4-322e4bfb5bba / deploymentName=main. That means the ID pair in metadata.json doesn't match any deployment record in our Azure logs.

Worth flagging up front: the new CI workflow is fresh, so it's also possible there's a bug on our side. Before assuming that though, a couple of things to double-check on your end:

• Confirm you actually deployed main.bicep (from this PR branch) to Azure, not just locally validated. The ADX cluster only indexes real deployments.
• Confirm the correlationId came from the properties.correlationId field on the actual deployment (e.g., az deployment group show --name <name> --resource-group <rg> --query properties.correlationId -o tsv).
• deploymentName: main is unusually generic — make sure this matches the --name you passed to az deployment group create (or the equivalent in PowerShell/portal).

If those all check out and you can confirm the deployment IDs are correct, let us know and we'll dig into the workflow. Otherwise, update metadata.json with the verified IDs and we'll re-run /validate.

[alex-frankel]

/validate

[mukesh-dua]

@alex-frankel I have re-run the deployment again today and updated the metadata.json with the test results. JFYI, these tests are performed in a BAMI subscription (non-Microsoft subscription), just in case that makes any difference.

[mukesh-dua]

@alex-frankel anything pending on our side?

[mukesh-dua]

#sign-off

[alex-frankel]

/verify