Foundry AIServices provisioning fails with InternalServerError

Jeff Brown 0 Reputation points
2026-08-16T17:16:17.2433333+00:00

I’m trying to create a Microsoft Foundry AIServices resource for a development environment.Subscription: PII Subscription offer: Sponsored_2016-01-01 Resource group: PII Tenant: PII

The Cognitive Services provider is registered. Quota checks show available capacity, and no Azure Policy results block Cognitive Services.

Creation fails with InternalServerError using unique names in two supported regions:

PII in westus3

PII in centralus

Both resources remain in Failed provisioning state. The original failed resource was PII.

Azure Resource Health reports Unknown with transient chronicity. No model deployments exist. What subscription entitlement, provider setting, or service-side issue could cause AIServices creation to fail this way?

I’m specifically looking for guidance before creating or deleting any additional resources.

Microsoft Foundry
Microsoft Foundry

A unified Azure platform for creating and managing AI models, agents, and applications with built‑in enterprise security, monitoring, and governance

0 comments No comments

2 answers

Sort by: Newest
  1. Thanmayi Godithi 11,825 Reputation points Microsoft External Staff Moderator
    2026-09-02T14:37:09.0866667+00:00

    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.

    Was this answer helpful?

    0 comments No comments

  2. Allan Solomon Mejia 7,915 Reputation points
    2026-08-16T21:59:07.75+00:00

    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.

    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.