New Anthropic claude-sonnet-4-6 GlobalStandard deployments fail with InternalServerError

Jeff Chastain 0 Reputation points
2026-06-24T13:29:19.8133333+00:00

Creating any new Anthropic model deployment (Sonnet, Opus, Haiku) on our Azure AI Foundry (Cognitive Services AIServices) account fails with an opaque InternalServerError, while existing Anthropic deployments on the same account continue to serve, and a different subscription successfully deploys the same models.

This is blocking a platform-readiness gate that provisions fresh AI Foundry stacks.

Exact error

At the deployment resource: provisioningState = Failed, properties.error = null. In the Activity Log / ARM operation:

ResourceOperationFailure
  → InternalServerError: "Internal Server Error."

No further details are surfaced. The Azure Portal reports the deployment as created, then it lands in Failed during setup.

Reproductions

All three Anthropic model families fail in the same way. Capacity was available in every case.

Deployment name Model/version SKU/capacity Result Time (UTC) correlationId
claude-sonnet-4-6-2 claude-sonnet-4-6 / 1 GlobalStandard / 2 Failed ~12:40 (deployment claude-sonnet-4-6-2, RG forge-dev)
claude-opus-4-8 claude-opus-4-8 GlobalStandard / 2 Failed 13:05:39 e35269ab-bf09-488d-9e48-63084ec3d53c
claude-haiku-4-5-2 claude-haiku-4-5 GlobalStandard / 2 Failed 13:06:35 536d7fd0-5faa-48ff-9c6e-da44b4ccd475

Also reproducible via ARM/Bicep on brand-new AI Foundry accounts in this subscription (multiple fresh accounts, both East US 2 and Sweden Central) — same InternalServerError.

What we have already ruled out

  • Not quota/capacity. GlobalStandard available capacity at the time of failure (via the modelCapacities API): claude-sonnet-4-6 = 48, claude-opus-4-6 = 100. Deployments requested only 1–2 units.
  • Not region-specific. Same failure in Sweden Central (80 Sonnet units free).
  • Not the model version / SKU. GlobalStandard version 1 is the available, correct version and matches the existing working deployment on the same account.
  • Not a client/template defect. Fails identically via the Azure Portal (point-and-click) and via ARM/Bicep.
  • Not a broad Azure outage. Azure Service Health shows no active service issues for the subscription/region.

What works (scoping contrast)

  • Existing Anthropic deployments on forge-dev-fd (claude-sonnet-4-6, claude-haiku-4-5) remain Succeeded and serve inference normally.
  • A different subscription (also East US 2) deploys the same claude-sonnet-4-6 model successfully — so Anthropic-on-Foundry is not broadly down.
  • New Anthropic deployments on this subscription succeeded as recently as ~2026-06-22 23:00 UTC; failures began afterward.

Assessment/hypothesis

The evidence points to a subscription-scoped condition that blocks creation of new Anthropic model deployments while leaving existing ones healthy — e.g. an Anthropic Marketplace / commerce-agreement state, a per-subscription new-deployment or organization-creation limit, or a backend provisioning fault — surfacing only as a generic InternalServerError.

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

Answer accepted by question author

Karnam Venkata Rajeswari 4,355 Reputation points Microsoft External Staff Moderator
2026-06-24T14:02:28.6566667+00:00

Hello @Jeff Chastain ,

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

The current deployment pattern suggests that the failure is occurring after the deployment request is accepted and during the backend provisioning process used to onboard and create new Anthropic deployments.

Given that existing deployments remain operational, capacity is available, and the issue reproduces across multiple regions and deployment methods, the following might be the reason for this behavior:

  1. Anthropic onboarding or organization provisioning workflows.
  2. Marketplace-backed entitlement or provisioning validation.
  3. Subscription-level eligibility or enablement state.
  4. Provider metadata validation during deployment creation.
  5. Backend provisioning operations that surface only as a generic InternalServerError.

Please check if the following steps help:

  1. Validating Subscription and Marketplace Configuration Please review:
    • Registration status of:
    • Microsoft.CognitiveServices
    • Microsoft.MarketplaceOrdering
    • Microsoft.SaaS
    • Marketplace access configuration.
    • Billing configuration and subscription eligibility.
    • Any recent policy, governance, entitlement, or agreement changes that occurred around the time deployments began failing
    A comparison between the affected subscription and the working subscription may also help identify any entitlement or onboarding differences.
  2. Reviewing Marketplace-Backed Provisioning Artifacts Please review whether Marketplace-backed resources associated with Anthropic onboarding were successfully created within the subscription. This can help determine whether deployment requests are successfully reaching the onboarding phase before the provisioning workflow fails.

The following references might be helpful , please check them out

We have reached out to you on private message for further assistance

 

Thank you

Was this answer helpful?

1 person found this answer helpful.
0 comments

2 additional answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Jubin Soni 0 Reputation points
    2026-06-27T22:26:35.32+00:00

    Hi @Jeff Chastain , thanks for the incredibly detailed writeup, makes it much easier to help.

    Your diagnosis is spot on. The fact that existing Anthropic deployments on the same account continue to serve while new ones fail, and that a different subscription deploys the same models successfully, strongly points to a subscription-scoped condition rather than anything wrong with your templates, regions, or capacity.

    The provisioningState = Failed with properties.error = null is the key tell here — that null error means the failure happened inside a backend provisioning workflow that didn't bubble up properly to the ARM surface. You can't fix this from the client side.

    What I'd do right now is open a support ticket and lead with these two correlation IDs directly: e35269ab-bf09-488d-9e48-63084ec3d53c and 536d7fd0-5faa-48ff-9c6e-da44b4ccd475. Ask them specifically to check the Anthropic Marketplace agreement state on your subscription and whether there's a per-subscription provisioning limit or entitlement flag that changed around 2026-06-22 23:00 UTC since that's when it broke.

    Also worth checking quickly on your end before the ticket: make sure Microsoft.MarketplaceOrdering and Microsoft.SaaS are both registered on the affected subscription and compare them against your working subscription. Sometimes a policy or governance change quietly unregisters a provider.

    The working subscription is your strongest evidence so keep referencing it in the ticket, same model, same SKU, same region, one works and one doesn't. That usually gets support past the quota checklist fast.

    Please upvote and accept the answer if it helps!

    Was this answer helpful?

    0 comments
  2. Alex Burlachenko 23,250 Reputation points MVP Volunteer Moderator
    2026-06-24T15:23:51.3+00:00

    Jeff Chastain hi, thx for sharing urs issue here at Q&A portal,

    looks subscription-scoped, not a normal model/region/capacity issue. The cleanest clue is that the same models deploy fine in another subscription, while existing Anthropic deployments in this subscription still serve. So inference path is ok, but new deployment provisioning is failing for this sub.

    Since Portal and ARM/Bicep both fail the same way, prob not ur template. And if modelCapacities shows free GlobalStandard capacity, the generic InternalServerError is likely hiding a backend provisioning/commerce/provider check.

    I’d ask MS to trace the failed ARM ops using these correlation IDs

    e35269ab-bf09-488d-9e48-63084ec3d53c

    536d7fd0-5faa-48ff-9c6e-da44b4ccd475

    Main things for them to check Anthropic Marketplace agreement state, subscription eligibility for new Anthropic deployments, any per-sub/org provisioning limit, and backend provisioning failures for Microsoft.CognitiveServices/accounts/deployments. https://learn.microsoft.com/en-us/azure/ai-foundry/how-to/create-model-deployments

    For ur readiness gate, I’d keep the working subscription as a control case in the ticket. That comparison is useful: same model, same SKU, same region, different subscription, one works and one fails. That usually gets support past the usual ‘check quota’ loop faster.

    this needs Foundry/Cognitive Services backend trace. From the client side, provisioningState = Failed + properties.error = null gives u basically nothing to fix.

    rgds,

    Alex

    &

    If my answer was helpful pls mark it and additional thx if u follow me at Q&A portal

    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.