Zero to Hero: Setting Up Microsoft Foundry Resources in Minutes

I spent 40 minutes last year setting up an Azure AI Studio project for a client demo. Wrong region, wrong SKU, forgot to enable project management flag, then the subdomain was already taken. The demo was in an hour. Not fun.

With Microsoft Foundry, that same setup takes maybe 5 minutes now. I'm not saying it's perfect — I've got complaints — but the resource creation story is honestly night and day compared to what we had before.

The actual steps, no fluff

Look, you need three things before you start: an Azure account, Azure CLI version 2.67.0 or later, and a role that lets you create resources. Azure Account AI Owner or Azure AI Owner on subscription works. If you're setting this up for a team, you need Owner role because you'll be doing role assignments later.

First you login and create resource group. Standard stuff.

az login

az group create --name my-foundry-rg --location eastus

Now here's where people mess up. The Foundry resource creation command — it's still using az cognitiveservices account create. Yeah, I know. The branding says "Foundry" but under the hood it's still cognitive services. You set --kind AIServices and --sku s0, and here's the flag that most tutorials skip mentioning early enough: --allow-project-management. Without this flag, you can't create projects under the resource. I forgot it once and had to update resource after. Wasted 10 minutes debugging why project creation was failing.

az cognitiveservices account create \
    --name my-foundry-resource \
    --resource-group my-foundry-rg \
    --kind AIServices \
    --sku s0 \
    --location eastus \
    --allow-project-management

Then you need a custom subdomain. This has to be globally unique — so don't use generic names like "test" or "demo" because they're taken. After that, create project under the resource with az cognitiveservices account project create. The hierarchy is: resource group → Foundry resource → project. Your team works inside project.

The portal way is easier honestly. Go to ai.azure.com, sign in, click "Create new project", pick name and region, done. But I always recommend CLI for anything you'll repeat more than twice. Script it, version control it, move on.

Deploying a model — the part that actually matters

So you've got your resource and project. Now you need a model deployed before anyone can actually, you know, use it.

Bash

az cognitiveservices account deployment create \
    --name my-foundry-resource \
    --resource-group my-foundry-rg \
    --deployment-name gpt-4.1-mini \
    --model-name gpt-4.1-mini \
    --model-version "2025-04-14" \
    --model-format OpenAI \
    --sku-capacity 10 \
    --sku-name Standard

That --sku-capacity 10 is your tokens-per-minute allocation in thousands. Start low. I mean it. I've seen teams deploy with capacity 50 on day one "just in case" and then get surprised by bill. Standard SKU is pay-as-you-go which is fine for development and most production workloads. You only need provisioned throughput if you're doing something with strict latency requirements — like real-time customer-facing chat with SLA commitments.

One thing I will say — model version matters. That 2025-04-14 string? It changes. If you're scripting this for CI/CD, you'll want to check available versions first or you'll get cryptic errors about model not being available in your region. I learned this the hard way when a deployment pipeline broke because Microsoft retired old model version and nobody on team noticed till Monday morning.

After deployment, verify it with the deployment show command. You're looking for "provisioningState": "Succeeded". If it says anything else, wait a minute and check again. Usually takes under 30 seconds but I've seen it take up to 2 minutes during busy periods.

Your project endpoint — this is what developers on your team actually need. It looks like https://<resource-name>.services.ai.azure.com/api/projects/<project-name>. You can find it in Foundry portal on project welcome screen. Copy it, paste it in your team's shared docs or .env template, and tell everyone the deployment name. That's basically all they need to start coding.

The team access thing nobody sets up properly

If you're the one creating resources for a team — and at OZ I am usually that person — you need to assign Azure AI User role to everyone who'll be building on this project. Not Contributor, not Owner. Azure AI User gives minimum permissions needed to build and test. I am thinking most teams over-permission by default because it's easier, but then you've got junior developers who can accidentally delete model deployments. Not great.

az role assignment create \
    --role "Azure AI User" \
    --assignee "developer@yourcompany.com" \
    --scope $PROJECT_ID

Pro tip — use Microsoft Entra security groups instead of individual emails. Adding 15 people one by one is painful. Create a group, add the group, done. When someone joins or leaves team, you update group membership instead of hunting through role assignments.

What happened was on one project we had 8 developers and I assigned roles individually. Then two people left, three new ones joined, and tracking who had access to what became its own part-time job. Security groups would've saved me hours.

The portal way is simpler for small teams though — go to Operate → Admin → select project → Add user. But again, doesn't scale.

One more thing. Make sure your team members are in same Microsoft Entra tenant. Sounds obvious but I've had guest accounts from partner companies that couldn't see project even with correct role assignments. The error message was completely unhelpful — just said "project not found." Took me 20 minutes to figure out it was a tenant issue.

And when you're done with everything — when project is finished or you're cleaning up after a workshop — az group delete removes the entire resource group and everything in it. Clean. Just make sure you're deleting right resource group, right?