Request quota increase through QMS

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

I keep this page open whenever I am working on Request quota increase through QMS 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 April 2026 I was on a call with Vinod the on-call engineer at an e-commerce shop in Powai, 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 note on context: I run a small consulting practice from Delhi, 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. Request quota increase through qms sits at the boundary between the developer-facing operation (the actual provision, deploy, or query) and the platform-facing controls (identity, network, quota, image, and lifecycle). 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 a quota fills up or an auditor asks why a setting is the way it is.

Two real symptoms I have seen in the last six months. One: a Dev Box project provisioned cleanly but every developer hit "could not provision" the next morning because the vCPU quota in Central India was 10 and the team was 12 engineers strong on 8-vCPU boxes. The fix was a 30-minute quota request; the lost time was a day. Two: an AI agent's tool call returned a clean 200 but the response was wrong because the OBO token had been issued with the wrong audience. The agent looked healthy in every dashboard; the user-visible answer was nonsense. Both bugs are absurd in hindsight. Both wasted a week.

The takeaway: request quota increase through qms 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 platform team.

Background you need before reading the official text

Dev Box runs on the same vCPU quota pool as standard Azure VMs in the chosen region. The default for a new subscription is small - often only 10 vCPUs in the relevant SKU family - which means a project with four developers on 16-vCPU dev boxes will hit the quota wall during the first afternoon. Request quota before you onboard users, not after.

The Quota Management Service (QMS) request is asynchronous. Microsoft usually approves within a few hours for sensible asks; sometimes within minutes. Ask for what you actually need plus 30% headroom, and include a one-line business justification. Vague requests get rejected or asked for more detail, which loses you a day.

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 of the portal matches the subscription you intend to change. This is the single most common cause of "I deployed to the wrong place" tickets I see.
3. Navigate to the resource - for Dev Box, type "Dev Centers" or "Projects" in the global search; for AI tools, type "Azure AI" or the specific resource type. Bookmark the resource page in your browser if you will revisit it; the portal navigation tree is too deep to repeat from scratch every time.
4. Open the property pane relevant to request quota increase through qms. The pane name in the May 2026 portal usually matches 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 for Microsoft Dev Box looks like this. Replace the names with your own resources:

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

az devcenter admin pool show \
  --pool-name "pool-vs-southindia" \
  --project-name "proj-platform" \
  --resource-group "rg-devbox-prod"

If you use PowerShell instead of Bash, the equivalent modules are Az.DevCenter for Dev Box and Az.CognitiveServices plus the Azure AI Foundry SDK for the developer AI tools. The cmdlet names mirror the CLI verbs.

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 (12 engineers, one Standard dev box each, 9am-9pm IST auto-stop weekdays, plus the platform overhead), my back-of-envelope is around ₹1,15,000 to ₹1,40,000 per month. Add Premium boxes for the two engineers doing heavy Unreal Engine work and expect another ₹35,000 on top.

The number I have seen go badly wrong: customers who let dev boxes run 24x7 without an auto-stop schedule, or who keep an unused agent endpoint provisioned "in case we need it" for months. Right-sizing usage windows is the single highest-leverage cost lever for Microsoft Dev Box.

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 provisioning is failing

1. Open the Activity log on the resource. Filter to the last 24 hours and look for any operation with status Failed.
2. Click the failing operation. Read the operation ID. The error in the activity log is usually more honest than the toast notification in the portal.
3. Revert the setting to the value you captured in step 5 of the walkthrough above. If you did not capture it, the activity log will show the previous value within the last 90 days.
4. Trigger a fresh provision. Confirm it completes within the expected SLA - usually under 25 minutes for a Dev Box, under 5 minutes for most AI tools data-plane operations.

Scenario 2: I deleted something I should not have

1. Most Microsoft Dev Box resources support soft delete with a 30-day retention. Open the Resource Group, switch to the deleted-resources view, and undelete the relevant item.
2. If soft delete is disabled (some customers do this for cost reasons, against my advice), file a Microsoft Support ticket within 24 hours. They may be able to recover from internal backups.
3. Document the incident in your team's runbook. Every customer who has had this happen ended up writing a permanent policy preventing soft delete from being disabled.

Scenario 3: I cannot reach 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 or Bicep, I confirm via the portal. Two surfaces, same result, before declaring victory.
2. Trigger an end-to-end smoke test. For Dev Box, that is provisioning a throw-away dev box from the developer portal and confirming the user can sign in. For AI tools, that is running a single representative tool call and checking the response shape against a known-good fixture. 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 metric into the team's PagerDuty rotation. For Dev Box, that is DevBoxProvisioningFailureCount. For AI tools, that is the per-resource availability metric plus a custom log query for 4xx rates above threshold. The alert text I use is plain: "X has failed in resource Y in region Z - 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 - regulated workloads, sovereign clouds, gov-specific SKUs, partner-tenant scenarios - are usually mentioned in a sub-heading but easy to skim past. Always grep the page for your specific scenario before committing.
• Skipping the smoke test. "The provision succeeded" is not the same as "a user can actually do their job from this". I have lost count of the customers who only discovered the network connection was misrouted when the first developer hit a slow internal package mirror.
• Mixing dev/test and production in the same Dev Center or AI workspace. The per-resource fee makes this look attractive, but it makes every audit harder, makes RBAC scoping clumsier, and makes the blast radius of a config mistake bigger.
• Letting secrets live in environment variables on a dev box. If you would not put your AWS root key in a public README, do not put it in a dev box image either. Key Vault references and managed identity are one short config step away. Use them.
• Forgetting to budget for cross-region capacity. The per-unit number is small, but it is billed continuously for the entire resource, not just when you actually fail over.
• Disabling soft delete to "save money". Soft delete is free on every resource type that supports it. The thing it costs you is the 30-day shadow copy of deleted items, which is exactly the safety net you will want when something goes wrong.

A real example from Chennai last March 2026

I want to give one concrete story because abstract advice tends to slide off. March 2026, I was helping a customer in Chennai - mid-size IT services firm, around 240 employees, two Azure subscriptions, one for production and one for non-prod. They had asked for a "platform 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 estate, the picture was familiar. Dev boxes provisioned for engineers who had left the company nine months earlier and never been deleted. An AI agent endpoint deployed for a proof-of-concept that had ended in February but kept billing for the model host. Three Compute Gallery image versions for every definition because nobody had pruned old versions in two years. None of these are individually catastrophic. Together they were 30% of the bill.

I have seen this fail when the platform team treats Microsoft Dev Box as fire-and-forget infrastructure. The bill grows by a paper cut a week until someone in finance notices. The fix was unglamorous. We built a tagging policy ("owner", "expires-on", "purpose"), wrote a tiny script that emails resource owners 14 days before the expires-on tag fires, and added a monthly review where the platform team walks every resource that has not been touched in 30 days. The bill dropped by ₹1.4 lakh the following month. The customer reinvested the saving in a second dev box pool in Mumbai to cut latency for their west-India staff.

The lesson I drew, and which I now tell every customer at kick-off: every Microsoft Dev Box tenant older than twelve months has at least one ghost resource. Often a dozen. The audit takes an afternoon and pays for itself within one billing cycle.

FAQ - the questions I get asked every week

Wrap-up

Request quota increase through qms 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.

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:

• Describe the requested quota increase
• Manage quota for Microsoft Dev Box resources
• Add a catalog to a project
• Apps that are required for Dev Box
• Assign dev center permissions to users
• Attach a network connection to a dev center