Azure DevTest Labs: Fix Setup, Policy & VM Errors
Why This Is Happening
I've seen it play out the same way on dozens of Azure tenants. A team lead spins up Azure DevTest Labs for the first time, excited to give developers self-service virtual machines without handing them the keys to production. Within a day or two, the tickets start rolling in , VMs won't provision, artifact installations are silently failing, autoshutdown isn't triggering, or someone's lab has ballooned the monthly bill because no one set a VM quota. Sound familiar?
Azure DevTest Labs is a genuinely well-designed service. It lets developers and testers quickly create and manage Azure virtual machines for development and testing with a self-service model, built-in cost control, and automation hooks that connect to your CI/CD pipelines. But that flexibility is also where it trips people up. There are at least four different layers where things can go wrong , the lab itself, the policy layer, the artifact/image layer, and the network/ARM layer, and the error messages you get in the Azure portal are often too generic to tell you which layer is the culprit.
The most common Azure DevTest Labs setup problems I see fall into a few buckets:
- VM provisioning failures caused by policy conflicts, the user's requested VM size isn't on the allowed list, or they've hit the per-user VM quota.
- Artifact installation errors where the artifact runs but silently exits with a non-zero code, leaving the VM half-configured.
- Autoshutdown not triggering because the lab's time zone setting was left at UTC and the schedule is evaluating against the wrong clock.
- Cost overruns that happen when no expiration dates are set on VMs and autoshutdown is the only guard rail, which it isn't designed to be alone.
- Custom image and formula confusion where lab users can't find the right base image because the custom image gallery wasn't connected properly.
What makes Azure DevTest Labs cost control problems particularly painful is that cost surprises don't show up until the end of the billing period. By then, the damage is done. The good news is that every one of these issues has a clear fix once you know which layer to look at.
I know this is frustrating, especially when your team is blocked waiting for a dev environment they were promised would be "self-service." Let's get it sorted. Browse all Microsoft fix guides →
The Quick Fix, Try This First
If your team is getting VM provisioning errors right now and you need something unblocked fast, here's the one check that resolves the majority of cases I see in the field.
Go to the Azure portal and navigate to your lab. In the left-hand menu under Settings, click Configuration and policies. Then, under the Virtual machines section, look at two things in sequence:
- Allowed virtual machine sizes, if this list is populated, any VM size not on it will silently block provisioning. Check whether the size your user requested (Standard_D2s_v3 is a common culprit because it's a reasonable default) is in that list. If it isn't, add it.
- Virtual machines per user, if a user has hit their limit, the portal will reject their VM creation request, sometimes with an unhelpfully vague message. Bump the limit temporarily, or identify which existing VMs the user owns and delete the ones they no longer need.
After making either change, have the user retry VM creation. Most of the time, this is all it takes. The lab's policy engine evaluates both of these constraints at the moment a VM is requested, so changing them takes effect immediately with no restart needed.
If VM creation still fails after those two checks, look at the Activity log for the lab resource in the Azure portal. Filter by "Failed" operations in the last hour. The operation detail will usually contain a more specific ARM error code that points you to the next step. Common ones are QuotaExceeded, InvalidTemplateDeployment, and ResourceNotFound, each points to a different layer of the problem.
Getting the Azure DevTest Labs lab creation step right saves you from cascading problems later. From the Azure portal home screen, type "DevTest Labs" into the search bar and select it from the results, don't confuse it with "Dev Box," which is a newer sibling service. Click + Create.
On the creation form, the fields that matter most are often the ones people skip through:
- Lab name: Keep it short and environment-specific. Names like
team-frontend-devare searchable later; names likelab1are not. - Region: Pick the region closest to your team. Azure DevTest Labs VMs live in the same region as the lab, you can't move them later without recreating the lab. If your team is distributed across time zones, pick the region where the majority work.
- Auto-shutdown: Enable this during creation, not as an afterthought. Set the shutdown time to something reasonable for your team's end of day, and critically, set the time zone to your local time zone. I've seen so many cases where this was left at UTC, causing VMs to shut down mid-afternoon for a US-based team.
After the lab deploys (usually under two minutes), open it and confirm the Overview blade shows the lab's resource group. All VMs, disks, and network interfaces created inside this lab will land in that resource group, knowing that matters for cost tracking and cleanup.
If the lab creation itself fails, check whether your Azure subscription has the Microsoft.DevTestLab resource provider registered. In the portal, go to your Subscription → Resource providers, search for Microsoft.DevTestLab, and register it if its status shows "NotRegistered."
This is where most Azure DevTest Labs cost control problems originate. The policy layer is powerful, but it has no defaults that protect you out of the box. You have to deliberately set it up.
Navigate to your lab → Configuration and policies. You'll see a set of policy categories on the left. Work through these in order:
Allowed virtual machine sizes: Click this and use the toggle list to select only the VM sizes appropriate for dev/test work. For most developer workstations, Standard_B2s, Standard_D2s_v3, and Standard_D4s_v3 are sufficient. Blocking GPU instances and memory-optimized sizes prevents accidental runaway spend by users who grab whatever looks familiar.
Virtual machines per user: Set this to 2 or 3 for most teams. One active VM plus one claimable VM is a typical developer need. If you leave this unlimited, a single user could spin up 20 VMs, and your subscription quota might be the only thing stopping them.
Virtual machines per lab: Set an aggregate cap. I recommend starting at 3× your team size. So if you have 10 developers, cap the lab at 30 VMs total. You can raise this later, it's much harder to explain why you need to raise a budget after it's been spent.
Auto-shutdown policy: Beyond the time setting, turn on the Send notification before auto-shutdown option and enter a webhook or email. This gives users a 30-minute warning and a chance to postpone shutdown once if they're mid-session. Without this, you'll get complaints that "the VM just turned off."
After saving policies, test them by creating a VM as a lab user (not as the lab owner, owner accounts bypass some policy checks). If you see an error during VM creation, the Activity Log on the lab will show the specific policy that blocked it.
One of the best features of Azure DevTest Labs is the ability to create custom VM bases with pre-installed software, so developers aren't spending their first hour on a new VM installing Node, VS Code, and Git. Getting this layer right is what makes the "self-service" promise actually work.
There are two approaches: custom images and formulas. A custom image is a snapshot of a configured VM, it's fast to deploy but heavyweight to maintain. A formula is a lightweight recipe that combines a base image (Azure Marketplace or custom) with artifact scripts, it's slightly slower to provision but much easier to update.
For most teams starting out, I recommend formulas. Here's how to set one up:
- In your lab, click Formulas (reusable bases) in the left menu.
- Click + Add and select a base, "Windows Server 2022 Datacenter" or "Ubuntu 22.04 LTS" are common starting points.
- On the next screen, attach artifacts. The DevTest Labs public GitHub repository has ready-to-use artifacts for common installs (Git, Chrome, .NET SDK, Node.js, etc.). Search for them by name in the artifact picker.
- Save the formula with a clear name like
frontend-dev-win11.
If artifact installation is failing silently, the fix is almost always in the artifact logs. After a VM provisions, go to the VM in the portal → Artifacts → click the failed artifact. The output log will show the exact exit code and stderr. Most failures are caused by artifact scripts trying to download software from the internet on a VM that doesn't have outbound internet access due to a restrictive NSG rule.
To connect a private Git repository containing your own custom artifacts, go to Configuration and policies → Repositories → + Add. You'll need a Personal Access Token with repo read access. Once connected, your private artifacts appear alongside the public ones in the artifact picker.
Azure DevTest Labs supports two provisioning models: users can claim a pre-created VM that a lab owner prepared, or they can create their own VM from the lab's formulas and images. Both work, but they have different failure modes.
For claimable VMs: The lab owner creates VMs in advance and marks them as "claimable." Users go to Claimable virtual machines and grab one. The failure I see most often here is that the VM was created by the owner account, which bypasses policy, so the VM ends up being a size that's not on the allowed list. When a regular user claims it, things look fine, but if they try to resize it later, the policy blocks them. Always create claimable VMs as a regular lab user account, not as the owner, so the policies are validated during creation.
For user-created VMs: Users click + Add from the lab's My virtual machines view, pick a base (formula or image), choose a size, and submit. If this fails, here's the diagnostic path:
# Check lab activity log via Azure CLI
az monitor activity-log list \
--resource-group <your-lab-resource-group> \
--start-time 2026-04-21T00:00:00Z \
--query "[?status.value=='Failed']" \
--output tableThat command will surface the exact ARM operation that failed and its error detail. Look for operationName values like Microsoft.DevTestLab/labs/virtualmachines/write, the status message next to it will tell you whether it was a quota issue, a policy block, or an ARM template error.
If you see InvalidTemplateDeployment, the formula or custom image has an ARM template problem. Go back to the formula definition and check whether all referenced artifacts still exist and whether the base image is still available in the Marketplace. Marketplace images occasionally get deprecated, if the base image version was hardcoded, it may now be missing.
Autoshutdown is not a cost control strategy by itself, it just means VMs are off at night. Disks, static IPs, and other attached resources still bill 24/7. Real Azure DevTest Labs cost control requires a combination of autoshutdown, VM expiration dates, and active monitoring.
Set expiration dates on VMs: When a lab user creates a VM, they can set an expiration date. After that date, Azure automatically deletes the VM and its resources. For sprint-based teams, I recommend defaulting to a 2-week expiration, long enough to finish a sprint, short enough to force a cleanup conversation. You can enforce a maximum expiration window by setting the Maximum expiration date for virtual machines policy in your lab's configuration.
Use the built-in cost tracking dashboard: In your lab, click Cost management in the left menu. The monthly estimated cost chart shows you spend by resource type and trends over time. Set a monthly target cost threshold here. When your lab hits 80% of that target, you'll get an alert email. This is the early warning system your finance team will thank you for.
Tag your VMs at creation time: In the lab's Configuration and policies → Tags section, you can set mandatory tags that get applied to every VM created in the lab. Tags like CostCenter, Project, and Owner make it possible to break down spend in Azure Cost Management by team or project rather than just by resource group.
For teams running Azure DevTest Labs CI/CD integration, make sure your pipeline scripts delete VMs after tests complete rather than just stopping them. A stopped VM still incurs disk and IP charges. The cleanup step in your pipeline should call the lab's REST API or use the Azure CLI to fully delete the VM:
az lab vm delete \
--lab-name <your-lab-name> \
--name <vm-name> \
--resource-group <lab-resource-group>Advanced Troubleshooting
Once you've worked through the basic setup and policy fixes, a handful of tougher problems tend to surface in enterprise environments. Here's how to approach them.
ARM Template Deployment Failures
Azure DevTest Labs uses ARM templates under the hood for all VM creation. When something goes wrong at this layer, the error often surfaces as a generic "deployment failed" message in the portal. To get the real error, go to the lab's resource group in the Azure portal → Deployments → find the failed deployment. The Error details tab will show you the exact ARM error, including which resource type failed and why.
Common ARM-layer failures include:
SkuNotAvailable, the requested VM size isn't available in your selected region. Solution: either change the region or select a different VM size in the lab policy's allowed list.QuotaExceeded, your subscription has hit its regional vCPU quota. Go to your subscription → Usage + quotas and request a quota increase for the affected VM family.StorageAccountNotFound, this happens when a custom image was created from a storage account that no longer exists or was moved. Recreate the custom image from the source VM.
CI/CD Pipeline Integration Issues
Azure DevTest Labs integrates well with Azure Pipelines and GitHub Actions for test automation. The most common problem I see here is authentication, the service principal used by the pipeline doesn't have the right role on the lab resource. The minimum required role is DevTest Labs User on the lab, plus Contributor on the lab's resource group if the pipeline needs to delete resources after tests.
Assign the role with:
az role assignment create \
--assignee <service-principal-object-id> \
--role "DevTest Labs User" \
--scope /subscriptions/<sub-id>/resourceGroups/<rg>/providers/Microsoft.DevTestLab/labs/<lab-name>Autostartup Schedule Not Working
Unlike autoshutdown (which is per-lab), Azure DevTest Labs autostartup schedules are set per VM. I see this catch people constantly, they set a lab-wide shutdown, assume startup works the same way, and then wonder why VMs aren't starting up Monday morning. To set a startup schedule, open the VM inside the lab → Auto-start → enable it and set the schedule. You must do this individually for each VM, or automate it via the lab's ARM template or Azure Policy at provisioning time.
Domain-Joined VMs and Network Problems
For enterprises that need VMs joined to an Active Directory domain, Azure DevTest Labs supports a domain-join artifact. However, the lab's virtual network must have line-of-sight to your domain controllers, either through a virtual network peering to your hub network or through an ExpressRoute/VPN connection. If domain join is failing, check that the artifact's credentials (domain, username, password, OU path) are correct and that the lab's subnet has the right DNS server configuration pointing to your domain controllers rather than Azure's default DNS.
InternalServerError responses from the DevTest Labs control plane, consistent ARM deployment failures that don't match any of the above error codes, or billing discrepancies where costs don't match the resources you see in the portal, it's time to open a support ticket. These are platform-side issues that no amount of configuration changes will fix. Open a case directly at Microsoft Support with the full Activity Log export (JSON format) from your lab's resource group, that's the data the support team will ask for first anyway, so bring it to save a round-trip.
Prevention & Best Practices
I want to share the setup pattern I've seen work best in teams that run Azure DevTest Labs without drama. It's not complicated, it's mostly about being deliberate at the start rather than fixing things reactively.
Establish a lab owner who isn't also a lab user. The owner role bypasses many policy checks. If the person administering the lab is also spinning up their own VMs, they can accidentally exceed limits that apply to everyone else, or they might not notice that policies are blocking regular users because their own experience is smooth. Keep a dedicated admin account as the lab owner and use a regular user account for actual development work.
Store your lab's ARM template in source control from day one. Azure DevTest Labs lets you export the lab's full ARM template from the portal. Do this after your initial configuration, commit it to Git, and keep it updated. This gives you a reproducible lab definition, if you need to spin up a second lab for a new team, or if the lab gets accidentally deleted, you can redeploy from the template in minutes rather than hours of manual portal clicking.
Version your artifact repositories. If you maintain a private artifact repository connected to your lab, use Git tags to version your artifacts. When a new version of an artifact breaks VM provisioning, you want to be able to pin back to the last known-good version without scrambling.
Review the cost dashboard weekly during initial rollout. In the first month of running Azure DevTest Labs, check the cost management dashboard every week. You'll catch things like forgotten VMs that someone created and never used, or a test that ran 200 VMs for an hour and no one noticed. After the first month, once patterns are established, monthly reviews are usually sufficient.
- Enable autoshutdown with the notification webhook on day one, before any user touches the lab
- Set a maximum VM expiration date policy of 30 days so VMs never live forever by default
- Add mandatory tags (Owner, Project, CostCenter) to every VM via lab tag policy before users start provisioning
- Connect the DevTest Labs public GitHub artifact repository so users have a wide library of vetted install scripts available out of the box
Frequently Asked Questions
What is Azure DevTest Labs and when should I actually use it?
Azure DevTest Labs is a managed Azure service that lets development and testing teams provision virtual machines in a self-service way, without giving everyone full Azure subscription access. You should use it when you need fast, repeatable VM provisioning for dev/test workloads, want cost control through policies and quotas, or need lightweight governance for a distributed team. It's not the right tool if you need production-grade infrastructure, it's specifically scoped to dev and test scenarios where speed and cost management matter more than production SLAs.
Why is my Azure DevTest Labs VM stuck in "Creating" and never finishing?
This is almost always an artifact installation problem. When a VM is provisioning, the base OS deploys quickly, but attached artifacts run sequentially and can block indefinitely if one hangs. Go to the VM in the portal → Artifacts and look for any artifact showing "Applying" for more than 10 minutes. Click it to see the log. If the log is empty, the artifact agent on the VM may have lost connectivity, check that the VM's NSG allows outbound HTTPS on port 443, which the artifact agent needs to phone home. Canceling the deployment and retrying after fixing the NSG rule usually resolves it.
How do I stop Azure DevTest Labs from running up a huge bill?
There are four layers of Azure DevTest Labs cost control that work together: autoshutdown schedules to stop VMs at night, VM expiration dates to auto-delete unused machines, VM count and size policies to cap what users can create, and the cost management dashboard to track trends. Using only one of these (autoshutdown alone is the most common single-layer approach) will still leave you exposed to disk costs on stopped VMs and forgotten machines. Set all four from the start. Also make sure your CI/CD pipelines that create test VMs are actually deleting them, not just stopping them, after test runs complete.
How does Azure DevTest Labs integrate with CI/CD pipelines like Azure Pipelines or GitHub Actions?
Azure DevTest Labs works well for test automation scenarios where your pipeline needs a clean VM environment for each run. The general pattern is: pipeline creates a VM from a lab formula at the start of a test job, runs tests against it, then deletes the VM when the job finishes. You authenticate using a service principal with the DevTest Labs User role on the lab. Microsoft publishes Azure Pipelines tasks for DevTest Labs in the marketplace that wrap the common operations (create VM, deploy artifact, delete VM) so you don't have to write raw CLI scripts. For GitHub Actions, you'd use the Azure CLI action with the az lab vm create and az lab vm delete commands.
Can I use my own custom VM images in Azure DevTest Labs, and how do I set that up?
Yes, custom images are one of the most useful features. You have two paths: upload a custom image from a VHD file, or capture an existing VM's disk as a custom image directly from the lab. For the capture path, create and configure a VM in your lab exactly how you want it, then from the VM's blade in the portal click Create custom image. After a few minutes, the image appears under your lab's Custom images section and can be used as a base for formulas or direct VM creation. For enterprise teams, connecting a Shared Image Gallery gives you versioned image management across multiple labs and is worth setting up once your image library grows beyond two or three images.
My team members can't see the lab or claim VMs, how do I fix permissions?
Lab access in Azure DevTest Labs is controlled by Azure RBAC. Users need the DevTest Labs User built-in role assigned on the lab resource to create and manage their own VMs, or DevTest Labs Reader if they only need to claim pre-created VMs. Go to your lab in the Azure portal → Access control (IAM) → + Add role assignment, select "DevTest Labs User," and add the relevant users or groups. If users are in a separate Azure AD tenant (common in partner or contractor scenarios), you'll need to first add them as Guest users in your Azure AD before you can assign the RBAC role. Owner-level access on the subscription does NOT automatically grant DevTest Labs User, it's a separate assignment on the lab resource itself.