Microsoft Dev Box Not Working? Fix It Fast

Microsoft Dev Box uses a specific three-tier role structure, and each tier must be configured independently. Missing even one breaks the chain. Here's what each role does and where to assign it.

DevCenter Dev Box User, This goes on the Project resource. Without it, developers can't see or create dev boxes. Go to your DevCenter → Projects → [Your Project] → Access control (IAM).

DevCenter Project Admin, This goes on the Project resource as well, but for team leads who need to create and manage pools. If your team lead is getting "insufficient permissions" when trying to create a pool, this role is missing.

For platform engineers who need full DevCenter control, they'll need the appropriate Azure RBAC role (typically Contributor or Owner) at the DevCenter resource level, not just the project level. That's a common mistake, assigning Contributor at the project level when the engineer needs to manage shared resources like network connections and image galleries that live at the DevCenter level.

To check all role assignments quickly, run this in the Azure Cloud Shell:

az role assignment list \
  --scope /subscriptions/{subscriptionId}/resourceGroups/{rgName}/providers/Microsoft.DevCenter/projects/{projectName} \
  --output table

Replace the placeholders with your actual subscription ID, resource group name, and project name. You should see at least one entry with DevCenter Dev Box User for your developer's user or group. If the list is empty, that's your problem, no one has been given access to that project yet.

After adding the role, you should see the affected user's dev box pools appear in the developer portal within 5–10 minutes. They'll show up as selectable options under the project name on the portal home screen.

A misconfigured dev box pool is one of the most common Microsoft Dev Box setup problems I encounter. Pools can be created using one of three image sources: YAML-based image definitions (the newest approach), custom images stored in Azure Compute Gallery, or preconfigured marketplace images like the Visual Studio ones. Each source has its own failure modes.

To check your pool's status, go to your DevCenter → Projects → [Your Project] → Dev box pools. Look at the Status column. If any pool shows Failed or Provisioning failed, click into it and look at the Health checks section, this is where Microsoft surfaces the actual error.

Common pool health check failures and their fixes:

• "Image not found", The image definition or gallery image the pool references has been deleted or renamed. Update the pool to point to a valid image.
• "Network connection failed", The network connection attached to the pool is broken. This usually means the associated Azure Virtual Network has changed (subnet deleted, NSG blocking traffic, etc.). See Step 4 for network fixes.
• "SKU not available", The compute SKU you selected for the pool isn't available in the region your network connection is configured for. Change the region in the network connection or select a different SKU.

If you're using YAML-based image definitions and seeing Dev Box image definition YAML errors, check the syntax carefully. The YAML-based customization format is strict about indentation and supported keys. Microsoft's schema currently supports tasks like installing WinGet packages, running PowerShell scripts, and setting environment variables. An invalid task name or incorrect indentation will cause the whole image build to fail silently in some cases, you'll just see the pool stuck in provisioning.

Once a pool's health checks all show green checkmarks, go back to the developer portal and refresh. A healthy pool in a Running state is what the developer sees when they hit the "New dev box" button.

A lot of the Microsoft Dev Box access denied issues I troubleshoot aren't permission problems at all, they're configuration completeness problems. The DevCenter needs several components wired together before anything works end-to-end, and the portal won't always tell you which piece is missing.

Go through this checklist in your DevCenter:

1. Network connections: Your DevCenter needs at least one network connection configured. Navigate to DevCenter → Networking → Network connections. If this list is empty, no dev box can ever be provisioned because there's nowhere to place it. You need to create a network connection that points to a virtual network in your Azure subscription.

2. Attached network in projects: Even if a network connection exists at the DevCenter level, it must also be attached to the specific project. Go to Projects → [Your Project] → Dev box pools and make sure the pool has a network connection selected. A DevCenter-level network connection that was never attached to a project pool is invisible to developers.

3. Compute gallery (for custom images): If you're using Azure Compute Gallery images rather than marketplace images, the gallery must be attached to the DevCenter. Go to DevCenter → Azure Compute Gallery and verify your gallery appears there. If it doesn't, click + Add and attach it.

4. Dev box definitions: Navigate to DevCenter → Dev box definitions. There should be at least one definition here that specifies the image source and storage configuration. If this section is empty, pools have nothing to build from.

After verifying all four of these components exist and are linked correctly, go back to your pool's health checks. They should all pass within a few minutes of the configuration being complete. If they still don't, check the Azure Activity Log for your DevCenter resource, it captures every configuration change and associated error with full detail.

Network configuration issues are the sneakiest Microsoft Dev Box problems because they don't always surface immediately. The dev box might provision successfully, connect fine through the developer portal, but then have no access to internal company resources, source code repos on-premises, internal package feeds, or corporate databases. The developer gets a working machine that can't actually do the job.

The network connection you attach to a pool determines two things: the Azure region where dev boxes are physically created, and the virtual network they join. Both of those decisions have downstream consequences you need to plan for.

Region selection: Dev boxes are created in the region of the network connection, not the region of your DevCenter. This is a critical detail that trips up a lot of platform engineers. If your company's internal resources are in East US and you accidentally configure your network connection to point to a virtual network in West Europe, your developers will have terrible latency to everything they need. Match the network connection region to where your corporate resources live.

Network Security Groups (NSGs): Check that the subnet your dev boxes use doesn't have NSG rules blocking required Microsoft service endpoints. Dev Box needs outbound connectivity to the Microsoft Intune management endpoints, Windows activation services, and the developer portal backend. A blanket "deny all outbound" NSG rule with no allow exceptions for Microsoft services will cause Intune enrollment failures and may prevent the dev box from appearing in the portal after provisioning.

Run this from within a dev box (via Remote Desktop or the browser-based connection) to test basic Microsoft service reachability:

Test-NetConnection -ComputerName manage.devcenter.microsoft.com -Port 443
Test-NetConnection -ComputerName login.microsoftonline.com -Port 443

Both should return TcpTestSucceeded: True. If either fails, your NSG or corporate firewall is blocking essential Microsoft Dev Box network traffic and needs an explicit allow rule added for those endpoints on port 443.

For organizations using Microsoft Dev Box in a corporate network with a proxy, make sure the proxy settings are included in the image (either the marketplace image configuration or your YAML customization tasks) so developers don't have to manually configure proxy settings every time a new dev box is created.

Every dev box that gets provisioned automatically enrolls in Microsoft Intune, that's by design, and it's one of the core enterprise management features of the service. But sometimes that auto-enrollment fails, leaving you with a dev box that shows as provisioned but can't be fully managed through Intune, or worse, one where the developer can't log in at all because a conditional access policy is requiring a compliant device.

The first thing to check is whether your Microsoft Intune subscription is properly linked to the same Microsoft Entra ID tenant your DevCenter is in. If your organization has multiple Entra tenants (common in large enterprises or post-merger environments), the Intune subscription needs to be in the same tenant as the DevCenter project. Cross-tenant Intune enrollment isn't supported for Dev Box.

To check Intune enrollment status for a specific dev box:

1. Open the Microsoft Intune admin center at intune.microsoft.com.
2. Navigate to Devices → All devices.
3. Search for the dev box by name (it will appear with the name you gave it in the developer portal).
4. If it's not there, the enrollment failed. If it's there, check the Compliance column.

If enrollment failed entirely, the most common cause is an Entra ID group policy or conditional access policy blocking device enrollment. Work with your Intune admin to check Devices → Enroll devices → Enrollment restrictions and make sure dev boxes (Windows corporate devices) aren't being blocked by a restriction policy.

Once Intune enrollment is working correctly, you can manage dev boxes exactly like any other Windows device in your fleet, applying configuration profiles, deploying applications, and running compliance checks. That's one of the major operational advantages of the service: your existing Intune policies apply automatically without extra setup.