Foundry AIServices provisioning fails with InternalServerError

Hello @Jeff Brown

Based on what you've tested, this doesn't look like a naming, quota, or basic resource-provider registration problem.

Microsoft's current documentation confirms that a Foundry resource is created as Microsoft.CognitiveServices/accounts with kind AIServices and SKU S0. It also notes that the subscription must be permitted to create this resource type.

Since:

• Microsoft.CognitiveServices is registered,
• quota/capacity is available,
• Azure Policy isn't blocking Cognitive Services,
• unique resource names fail,
• two different supported regions fail, and
• the resources reach a terminal Failed state with only InternalServerError,

I would focus next on the subscription entitlement and Cognitive Services backend provisioning path, especially since this is a sponsored subscription.

As a useful diagnostic, try creating the resource directly through Azure CLI:

az cognitiveservices account create \
  --name <unique-name> \
  --resource-group forgewarden-dev \
  --kind AIServices \
  --sku S0 \
  --location westus3 \
  --yes

This is the creation method documented by Microsoft. If that also returns InternalServerError, it would further rule out the Foundry portal itself.

I would not keep deleting and recreating resources across regions. An ARM InternalServerError is intentionally generic and doesn't expose the underlying service-side failure to the customer. The Cognitive Services REST API documentation confirms that unsuccessful account creation can return an ErrorResponse, but it doesn't provide a client-side remediation for a generic internal server failure.

At that point, Microsoft Support would need to inspect the backend operation. Provide them with the subscription offer/type, failed resource IDs, regions, exact UTC timestamps, Activity Log operation/correlation IDs, and the CLI failure output. Ask them specifically to verify whether the subscription is entitled to provision Microsoft.CognitiveServices/accounts with kind=AIServices.

So I wouldn't treat this as a confirmed regional capacity issue yet. The fact that independent AIServices resource creation fails in multiple regions on the same subscription makes a subscription-specific entitlement or service-side provisioning issue the stronger possibility.

Sharing you these references:

Microsoft Learn – Create a Foundry resource | https://learn.microsoft.com/en-us/azure/ai-services/multi-service-resource?

Microsoft Learn – Cognitive Services Accounts Create REST API | https://learn.microsoft.com/en-us/rest/api/aiservices/accountmanagement/accounts/create?

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

Hi @Jeff Brown,

Thank you for providing the additional details.

Based on your findings:

• Microsoft.CognitiveServices is registered.
• The failures occur with multiple unique resource names.
• The failures occur in multiple supported regions (westus3 and centralus).
• The resources reach a terminal Failed provisioning state with InternalServerError.
• Azure Resource Health reports Unknown.

This makes a client-side configuration issue less likely and suggests either a subscription eligibility/entitlement validation issue or a service-side provisioning failure occurring during AIServices resource creation.

One detail that stands out is the subscription offer type Sponsored_2016-01-01. While InternalServerError itself does not identify the root cause, resource creation can fail if backend validation determines the subscription is not eligible for a particular resource type or feature. The provisioning workflow does not always surface those checks as a user-friendly error.

Before creating additional resources, I would recommend collecting:

• Activity Log Correlation ID and Operation ID for one of the failed deployments.
• The full Activity Log JSON for the failed Microsoft.CognitiveServices/accounts/write operation.
• The resource IDs of the failed AIServices resources.

If the same failure occurs through both the Azure portal and Azure CLI/ARM deployment, that would further indicate the failure is occurring in the service provisioning path rather than the Foundry experience itself..

Please let us know if you can share the correlation ID and Activity Log details from one of the failed deployments, and we can help review them further.