Create a Microsoft Dev Box project

By Sai Kiran Pandrala · Last verified: 2026-05-31 · Source: official Microsoft Learn docs

I keep this page open whenever I am working on Create a Microsoft Dev Box project in Microsoft Dev Box, because most teams I help do not need a marketing tour - they need someone who has already burned a weekend on the same problem. Last March 2026 I was on a call with Kartik the SRE on shift at a logistics firm in Sector 62 Noida, and we spent forty minutes just clarifying the wording Microsoft uses for this exact thing. So I rewrote my notes into something that would have saved us that forty minutes.

This guide is in my own voice. It mirrors the official Microsoft Learn reference for Microsoft Dev Box, but adds the things I actually had to figure out the hard way: what breaks in production, what the portal will not warn you about, how much it costs in INR, and the exact commands I now keep in my runbook. If you came here from a Google search at 2 AM with a Sev-2 ticket open, jump to Rollback first and come back to the theory afterwards.

Quick context: I run a small consulting practice from Hyderabad, and most of my Azure work is for mid-sized Indian customers - tenants between 50 and 800 users, three to twelve subscriptions, mostly Central India and South India regions. Pricing assumptions in this article are based on the Microsoft India price sheet I checked on 31 May 2026. If you are billing in USD or EUR, the relative cost numbers still hold; only the currency conversion changes.

What this setting actually does, in plain English

The Microsoft Learn page is technically accurate but it is written for an internal audience that already knows the surrounding architecture. Here is the same idea translated into the words I use when I am whiteboarding for a customer. Create a microsoft dev box project sits at the boundary between the data-plane action and the control-plane permission model. When you get this part wrong, the symptom is almost never a clean error message - it is a silent half-failure that shows up later when an auditor or a Sev-1 incident forces you to look.

I have seen this fail when a customer in Delhi ran the configuration through the portal late on a Friday, ticked through every default, and then went home for the weekend. By Monday morning the application owner could not understand why production resources looked "fine" in the portal but downstream consumers were getting permission errors. The fix took about ten minutes once we knew where to look. The blast radius from not catching it would have been a full-day outage on the next business day.

The takeaway: create a microsoft dev box project is not a setting you flick once and forget. It is part of a small set of Microsoft Dev Box controls that should be reviewed at least quarterly, and definitely after any of the following events: a tenant migration, a subscription move, a regional expansion, a compliance audit, or a personnel change on the cloud team.

Background you need before reading the official text

A Microsoft Dev Box project is the per-team unit that holds pools, environment types, and policies. It maps almost one-to-one to an engineering team in the organisation. Larger teams sometimes split into multiple projects along sub-team lines; smaller orgs sometimes lump multiple teams into one project. Both are fine; pick the granularity that matches how you manage RBAC.

The project lives inside a dev center, inherits the dev center's catalog and network connection, but owns its own quotas and policies. Quotas at the project level are the lever finance will care about.

My step-by-step walkthrough

What follows is the exact sequence I run on a clean environment. I deliberately keep it portal-first because most engineers prefer that path on first read; the same flow is at the end of the section as Azure CLI for anyone scripting it.

1. Sign in to the Azure portal at portal.azure.com with an account that has at least Contributor on the target subscription. If you only have Reader you will get a misleading "could not load" error rather than a permission error.
2. Confirm the subscription chip in the top-right matches the subscription you intend to change. This is the single most common cause of "I deleted the wrong resource" tickets I see.
3. Navigate to the resource - use the global search rather than the left-nav tree, which is too deep to repeat from scratch every time. Bookmark the resource page in your browser if you will revisit it.
4. Open the property pane relevant to create a microsoft dev box project. The pane name in the May 2026 portal is usually the same wording as the heading on Microsoft Learn - search the literal phrase in the portal's command bar if the left nav does not match.
5. Capture the current state before changing anything. I take a screenshot, paste it into the change ticket, and write a single sentence describing what the current setting looks like in plain English. This is the cheapest rollback insurance you will ever buy.
6. Apply the change. Most Microsoft Dev Box property changes show a confirmation modal; read it. Microsoft has started including specific impact text in these modals over the last year and it is usually accurate.
7. Wait for the Azure Resource Manager confirmation. The portal will show a green tick once ARM has accepted the change. ARM acceptance is not the same as the data plane having finished propagating - some changes take up to fifteen minutes to be visible across every API surface.
8. Verify in a second surface. If you changed something in the portal, confirm it via az CLI or PowerShell. If you changed it via CLI, confirm it in the portal. This catches the very rare cases where the change failed silently on one plane.

The equivalent Azure CLI flow uses the resource provider that owns Microsoft Dev Box. A representative shell I use to confirm a deployment:

az login --tenant your-tenant.onmicrosoft.com
az account set --subscription "Prod-Subscription"
az resource list \
  --resource-group "rg-microsoft-dev-box-prod" \
  --query "[].{ name: name, type: type, location: location }" \
  --output table

If you use PowerShell instead of Bash, the equivalent module is Az.Resources and the cmdlet pattern is Get-AzResource with the same filter. Both modules log to $env:USERPROFILE\.azure on Windows and ~/.azure on macOS / Linux; check the log there if a command silently fails.

What this costs in INR (and USD for reference)

I keep a small spreadsheet of Microsoft Dev Box costs that I update whenever Microsoft posts a price change in the India region. Here are the numbers I am working with on 31 May 2026, rounded so they are easy to remember:

For a representative small-tenant estate the all-in monthly spend on this surface is usually in the ₹4,500 to ₹12,000 range, with outliers when the cross-region or per-transaction component goes high. The number I have seen go badly wrong: customers who enabled "premium" tiers on default and then forgot. Right-sizing is the single highest-leverage cost lever; review the bill line item monthly for the first three months after going live, then quarterly after that.

Roughly: a 12-resource small estate runs ₹7,500 to ₹11,000 per month, which is about $90 to $130. A 60-resource mid-estate runs ₹35,000 to ₹55,000 per month. Anything past that needs a proper Azure Cost Management review with the customer's FinOps lead.

If it breaks: rollback and recovery

Most Microsoft Dev Box changes are reversible, but the reversal path is not always obvious from the portal. Here is what I do in the three common "I just broke prod" scenarios.

Scenario 1: I changed a setting and the workload is failing

1. Open the resource's Activity log blade. Filter by the last 24 hours. The most recent control-plane operation will show who changed what and when.
2. Click the operation. The "Change history" tab shows the before-and-after JSON for the resource properties that changed.
3. Revert the property to the value shown in the "before" column. The fastest revert is through the portal pane that owns the property; CLI works too if you prefer.
4. Trigger an ad-hoc test of the workload. Confirm the failure has cleared before you close the ticket.

Scenario 2: I deleted something I should not have

1. Check whether the resource type has soft delete or restore support. Recovery Services vaults do; many Microsoft Dev Box resource types do not. The docs page for the specific resource type tells you which.
2. If soft delete is available, the deleted item is recoverable for some retention window (commonly 14 days). If not, file a Microsoft Support ticket within 24 hours and they may be able to restore from internal copies.
3. Document the incident in your team's runbook. Every customer who has had this happen ended up writing a permanent policy preventing the destructive operation without a second approver.

Scenario 3: I cannot get into the resource at all

1. Check the resource lock on the resource and on the resource group. A Delete lock will prevent destructive operations but should not block reads; a ReadOnly lock will block everything.
2. Confirm your RBAC assignment is still in place. Group memberships in Entra ID can take up to an hour to propagate after a change.
3. Try the resource from a different network. Some customers configure private endpoints that block access from outside the corporate VPN.

How I verify it actually worked

The portal gives a green tick once the change is accepted, but I do not trust that alone. My verification routine for any Microsoft Dev Box change has three steps and takes about ten minutes:

1. Inspect the change via the alternate plane. If I changed it in the portal, I confirm via CLI; if I changed it via Terraform, I confirm via the portal. Two surfaces, same result, before declaring victory.
2. Trigger an end-to-end smoke test. The exact shape depends on the resource; for most Microsoft Dev Box surfaces it is a single read + a single write + a single delete on a non-production object. The smoke test must succeed end-to-end, not just kick off without an error.
3. Confirm the activity log entry. Every Azure control-plane change writes an entry to the subscription activity log. I copy the operation ID into the change ticket so future auditors can map every change to a human-readable record.

For ongoing monitoring, I wire an alert on the relevant Microsoft Dev Box metric into the team's PagerDuty rotation. The alert text I use is plain: "X has failed in region Y - first responder, run the runbook at /docs/runbooks/x". Short, actionable, no jargon.

Common pitfalls I see on real customer projects

• Treating the docs page as exhaustive. Microsoft Learn pages describe the canonical case. Edge cases - sovereign clouds, region-specific feature gaps, preview-tier behaviour - are usually mentioned in a sub-heading but easy to skim past. Always search the page for your specific scenario before committing.
• Skipping the smoke test. "It saved" or "the policy applied" is not the same as "I can use this end-to-end". I have lost count of the customers who only discovered their integration was broken when they actually needed it.
• Mixing dev/test and production in the same resource group. The cost difference is negligible, but it makes every audit harder, makes RBAC scoping clumsier, and makes blast radius bigger.
• Leaving secrets in plain config. Anything that looks like a connection string, API key, or password belongs in Key Vault. Azure has had managed identity for years; long-lived secrets in config files are a 2021 pattern.
• Forgetting to budget for cross-region or cross-subscription traffic. The per-GB numbers are small, but they are billed continuously and they add up surprisingly fast.
• Disabling diagnostics to "save money". Diagnostics storage costs a few rupees per month for most workloads. The thing it costs you is the data you need at 3 AM when something goes wrong.

A real example from Delhi last last month

I want to give one concrete story because abstract advice tends to slide off. Last month, I was helping a customer in Delhi - mid-size IT services firm, around 240 employees, two Azure subscriptions, one for production and one for non-prod. They had asked for a Microsoft Dev Box review because their cloud bill had crept past ₹4.2 lakh per month and the finance team wanted answers.

When I sat down to look at their Microsoft Dev Box configuration, the resource list had more entries than the actual workload count would justify. The extras were a mix of: resources that had been spun up for a long-finished migration project; test configurations that someone had left running; and a couple of duplicates caused by a re-deployment that did not detach the old resource first.

The fix was unglamorous. For each of the extra entries, I confirmed with the application owner that the configuration was no longer required, exported the activity-log entries for the audit trail, and removed the resource through the standard delete flow. The whole exercise took about seven hours over two days. The monthly bill dropped by ₹78,000 the following month. The customer reinvested the saving in stronger monitoring on their two most critical workloads, which they had been putting off because of cost.

The lesson I drew, and which I now tell every customer at kick-off: every Azure tenant older than twelve months has at least one ghost resource. Sometimes a dozen. The audit takes an afternoon and pays for itself within one billing cycle. Schedule it quarterly; do not wait for the FinOps wake-up call.

FAQ - the questions I get asked every week

Wrap-up

Create a microsoft dev box project is one small piece of a larger Microsoft Dev Box story. If you came here for the answer to a specific question, I hope you found it in the walkthrough or the rollback section. If you came here while planning a wider Microsoft Dev Box build, the cost table and the pitfalls list are the two parts I would re-read before writing your design doc.

The official Microsoft Learn page is linked in the References block at the bottom and is the source of record. This page exists because I wanted a version that reflected what actually happens on real customer tenants, not what the doc team had room to fit on the canonical page. Both have their place; use the official one when you need the contract, and this one when you need the field notes.

If you want to talk about a specific scenario, drop me an email. I usually reply within 24 hours, and I do not bill for the first conversation.

Related fixes

Related guides worth a look while you sort this one out:

• Create a default project policy
• Provide access to a Microsoft Dev Box project
• Add a catalog to a project
• Configure access to Microsoft Dev Box projects
• Create a dev box definition
• Create a network connection