Bicep-created Azure AI Foundry resource not recognized by new Microsoft Foundry portal (ai.azure.com) — CLI works fine

[mhadaily]

When creating a Microsoft Foundry resource
(Microsoft.CognitiveServices/accounts with kind: AIServices) using Azure
CLI, the resource and its project appear correctly in the new Microsoft
Foundry experience at ai.azure.com.

However, when creating the exact same resource using Bicep, the portal
still shows the old "Azure AI Foundry" classic experience and prompts to
"Try the new Microsoft Foundry experience" — but the project never appears in
the dropdown.

Environment

• API version: 2025-09-01 (GA)
• Region: swedencentral
• Resource kind: AIServices
• SKU: S0
• Date tested: February 2026

What works ✅ — Azure CLI

# Step 1: Create the Foundry resource
az cognitiveservices account create \
    --name my-foundry-resource \
    --resource-group my-rg \
    --kind AIServices \
    --sku s0 \
    --location swedencentral \
    --allow-project-management

# Step 2: Set custom subdomain
az cognitiveservices account update \
    --name my-foundry-resource \
    --resource-group my-rg \
    --custom-domain my-foundry-resource

# Step 3: Create project
az cognitiveservices account project create \
    --name my-foundry-resource \
    --resource-group my-rg \
    --project-name my-project \
    --location swedencentral

Result: Resource + project appear in the new Foundry portal immediately. ✅

Inspecting the CLI-created resource via REST API shows:

{
	"allowProjectManagement": true,
	"customSubDomainName": "my-foundry-resource",
	"disableLocalAuth": null,
	"publicNetworkAccess": "Enabled",
	"restrictOutboundNetworkAccess": null,
	"networkInjections": null,
	"networkAcls": null
}

What doesn't work ❌ — Bicep

resource account 'Microsoft.CognitiveServices/accounts@2025-09-01' = {
  name: 'my-foundry-resource'
  location: 'swedencentral'
  kind: 'AIServices'
  identity: { type: 'SystemAssigned' }
  sku: { name: 'S0' }
  properties: {
    allowProjectManagement: true
    customSubDomainName: 'my-foundry-resource'
    publicNetworkAccess: 'Enabled'
    disableLocalAuth: false
    restrictOutboundNetworkAccess: false
    networkAcls: {
      defaultAction: 'Allow'
      bypass: 'AzureServices'
    }
  }
}

resource project 'Microsoft.CognitiveServices/accounts/projects@2025-09-01' = {
  parent: account
  name: 'my-project'
  location: 'swedencentral'
  kind: 'AIServices'
  identity: { type: 'SystemAssigned' }
  sku: { name: 'S0' }
  properties: {}
}

Result: Resource deploys successfully (provisioningState: Succeeded), but
the new Foundry portal does NOT show the project. It still shows the classic
"Azure AI Foundry" experience with an "upgrade" prompt. ❌

Inspecting the Bicep-created resource via REST API shows:

{
	"allowProjectManagement": true,
	"customSubDomainName": "my-foundry-resource",
	"disableLocalAuth": false,
	"publicNetworkAccess": "Enabled",
	"restrictOutboundNetworkAccess": false,
	"networkAcls": {
		"bypass": "AzureServices",
		"defaultAction": "Allow",
		"ipRules": [],
		"virtualNetworkRules": []
	}
}

Root cause analysis

We did a side-by-side comparison of the ARM properties between the CLI-created
and Bicep-created resources. The key difference:

Property	CLI-created (works ✅)	Bicep-created (broken ❌)
disableLocalAuth	null	false
restrictOutboundNetworkAccess	null	false
networkAcls	null	{ bypass: "AzureServices", defaultAction: "Allow" }

Even though false and null are semantically equivalent for these properties,
it appears the Foundry portal filters on null vs explicit values.

Bicep uses ARM PUT (full resource replacement), which writes explicit
values for all specified properties. The CLI uses a different creation path
that leaves unset properties as null. Once these properties are set to
explicit values via Bicep's PUT, there is no way to reset them back to
null — Azure's ARM layer persists the explicit values permanently.

What we tried

1. Removed networkAcls and restrictOutboundNetworkAccess from Bicep —
   ARM PUT still sets restrictOutboundNetworkAccess: false (explicit) instead
   of leaving it null.
2. Set restrictOutboundNetworkAccess: false explicitly — same result,
   portal doesn't recognize it.
3. Used az cognitiveservices account update to try resetting values to
   null — properties persist as explicit values.
4. Used az rest --method PATCH to try clearing networkAcls — Internal
   Server Error or values persist.
5. Confirmed API version 2025-09-01 (latest GA that supports all resource
   types including capabilityHosts).
6. Compared with official Microsoft samples from
   microsoft-foundry/foundry-samples
   — our Bicep structure matches exactly.
7. Added networkInjections to the CLI-created resource via PATCH — it
   still appears in the new portal, confirming networkInjections alone is NOT
   the issue.

Workaround

We worked around this by creating the Foundry account and project via CLI in
our deployment script (before Bicep runs), then referencing them as existing
in Bicep for model deployments, connections, capability hosts, etc.:

# deploy.ps1 — Pre-Bicep step
az cognitiveservices account create --name $name --resource-group $rg --kind AIServices --sku s0 --location $location --allow-project-management
az cognitiveservices account update --name $name --resource-group $rg --custom-domain $subdomain
az cognitiveservices account project create --name $name --resource-group $rg --project-name $projectName --location $location

# Then Bicep references them as existing:

// foundry.bicep — references CLI-created account
resource account 'Microsoft.CognitiveServices/accounts@2025-09-01' existing = {
  name: foundryResourceName
}

// Model deployment, diagnostics, connections, capability host etc. work fine as child resources
resource modelDeployment 'Microsoft.CognitiveServices/accounts/deployments@2025-09-01' = {
  parent: account
  name: 'gpt-4o'
  // ...
}

Questions

1. Is this a known issue with the new Foundry portal filtering on explicit
   false vs null?
2. Is there a Bicep property or pattern that creates the resource in a way the
   new portal recognizes?
3. Will this be fixed so Bicep-created resources are treated the same as
   CLI/portal-created ones?
4. Is there a way to reset ARM properties back to null once they've been set
   to explicit values?

Any tips or insights from anyone who has successfully deployed a new Foundry
experience resource purely via Bicep/ARM templates would be greatly
appreciated.

Tags: azure, azure-ai-foundry, azure-bicep, microsoft-foundry,
azure-resource-manager