Microsoft Dev Box - Simply Explained

0:00 Welcome to the M365 FM podcast, where we explore the people, ideas and technologies shaping the future of work. Why your next work computer might not be in the room. Your next work computer might never sit on a desk. Microsoft Dev Box is a full windows workstation that runs in a Microsoft data center, and you reach it from whatever screen you already own. Developers call these machines dev boxes, and each one arrives fully set up for a project instead of empty. A developer can keep one per project and delete it when the work is done. Welcome to the M365 FM podcast, where we explore the people, ideas and technologies shaping the future of work. Today we're explaining Microsoft Dev box in plain English, including one thing that changed this year and affects anyone thinking of using it.

0:42 What Microsoft Dev Box actually is. Microsoft's own description is the clearest place to start. Dev box gives developers self-service access to ready to code cloud workstations, and Microsoft calls each one a dev box. That phrase about self-service does a lot of quiet work, because it means a developer never has to file a ticket and wait for someone in it. The dev box itself is a real windows computer. It isn't a window into somebody else's software. It runs on an Azure Virtual Machine with premium SSD storage behind it. So the processor, the memory, and the disk all belong to Microsoft rather than to the person typing. You reach it through a developer portal, and the screen in front of you can be a work laptop or a desktop or a tablet. What arrives is the part that matters most. A dev box comes pre-configured for one specific project with the tools, the source code, and the pre-built pieces already in place.

1:25 So a developer starts working. Instead of spending a day installing things, Microsoft builds those machines from one of three sources. An image definition is a small configuration file that installs and sets up software. A custom image is one your own company keeps in Azure. A ready made image from the Azure Marketplace can arrive with Visual Studio already on it. The word ready is worth taking literally here, because it changes what a first day looks like on a normal machine. A new developer loses hours to installs licenses and version mismatches on a dev box. That work happened in the background while the machine was being built. It's worth separating this from a few things it sounds like, because the name fools people, this isn't a laptop your company ships to your house, and it isn't a program you install on your own computer. You might think Devbox is hardware you buy, but it's really a service your company runs.

2:08 The work itself stays on the devbox rather than on whatever device happens to be in your hands. And that single difference is why some companies care about it at all. Part of the confusion is the name itself. Since Devbox sounds like hardware, you would unbox the box is the idea now, not the object. So picture the whole idea in one line. It's a complete work computer that lives in a Microsoft data center, and it's set up for one job before you ever sign in the four pieces that make Devbox work, Devbox is built from four parts that fit inside each other. Once you see the shape, you can follow any conversation about it without getting lost. The biggest part is the dev center. A dev center is a container that holds projects along with the shared settings they all use, like which networks and which images are allowed.

2:49 Microsoft says most organizations need just one, which tells you this is a setup decision rather than a daily one. Inside the dev center sits the project. A project represents a team or a business function, and it's the doorway developers actually walk through. Each project belongs to one dev center, so when two teams need completely separate rules, they usually end up with separate projects. Instead of arguing over settings inside the project set the dev box pools. A pool is a group of dev boxes managed together, and everything in that group shares the same image compute, size, storage, and network connection. This is where a team lead decides what kind of machine people get. A front end team might get a pool loaded with node JS tooling, while a data science team gets one with Python and data tools.

3:29 Each developer then picks the pool that matches the work in front of them. There's one more thing to notice about pools, and it explains a lot of later decisions. A pool is tied to a network connection, and that connection carries a region. So the pool decides not just what kind of machine you get, but where that machine physically lives. That's why a company with developers in three countries usually ends up with three pools instead of one. The smallest part is the dev box, which is the actual workstation a developer creates for themselves. Two supporting pieces hold the whole structure together. A catalog is a collection of setup tasks and scripts that run while a machine is being built, and a project policy is the rule book that limits a project to approved images, networks and sizes. The company also keeps an older option called a dev box definition, which bundles the image and the size into a single choice.

4:12 It still works, but Microsoft now points teams toward image definitions, custom images, or marketplace images because those latter project pick, compute and storage separately. There's a reason this structure is worth learning. Rather than skipping, the design lets a platform team build the shape once and then let developers help themselves inside it. And that's the difference between a service and a favor. It's also where the most common mistakes hide, and we'll get to those. What makes a dev box feel like your own PC? Most of what makes a dev box feel personal happens before a developer ever touches it. It's worth walking through because it answers the security question people ask next. Identity comes first, and it's stricter than most people expect. Dev box runs on Microsoft Entra ID, which is the same sign in system companies already use for Microsoft three.

4:54 Sixty five it supports work and school accounts only. A personal email address won't get you in, and the older guest access feature has been retired. management comes next. Every Devbox enrolls itself in Microsoft Intune and is treated like any other windows device on the company network. That's how a company pushes apps, settings, and updates to it in the same way it manages a laptop. It's also how a compromised machine can be isolated while its owner gets back to work on a fresh one. Because the machine is a managed device, a company can attach conditions to who gets in common. Policies require multifactor authentication, and restrict access to compliant devices. A company can switch off clipboard redirection, so code can't be copied onto a personal laptop, and it can use privilege management so developers install what they need without holding local admin rights.

5:37 Then there's the network. And here you get a genuine choice. A Microsoft hosted network connection means Microsoft runs the plumbing and the setup stays simple and cloud only. And Azure Network Connection means the company runs the plumbing itself and can reach on premises systems. The region attached to that connection decides where the machine physically lives, which is why placing a pool near the developer matters more than it sounds. Connectivity runs through Azure Virtual Desktop, and no inbound connection is ever made from the internet to your dev box. One detail catches almost everyone. The disk is encrypted by default with a key. Microsoft managers and the company warns that turning on BitLocker yourself can lock you out of the dev box you were trying to protect. Linux work is handled through Windows Subsystem for Linux, so the machine underneath stays windows no matter what you're building on top of it.

6:21 A normal Tuesday on a dev box. The best way to see this is through one new hire. A developer joins a team on a Monday. Signs into the developer portal, picks a pool, and asks for a dev box. Microsoft is honest that this isn't. Instant provisioning takes twenty five minutes or more because the machine has to be created. Join entry ID, register with Intune and run the setup tasks for the project. Compare that to the old way where a hardware order could eat the first week before anyone wrote a line of code. When the machine is ready, the tools are already there. There's no setup weekend, and there's no argument about whose laptop behaves differently because everyone in that pool started from the same image. Then comes the part that surprises people. A developer isn't limited to one machine. They can create a separate dev box for each project or task and delete them once the work wraps up.

7:04 A messy experiment never has to touch the code they're paid to ship. They can connect from any device they own, and the work lives on the dev box instead of the device in their hands. There's a practical side to this that rarely gets mentioned when a dev box breaks or gets compromised. The fix looks more like swapping a light bulb than repairing a car. The machine can be isolated and the developer is back at work on a fresh one built from the same image. Because nothing important lived only on that disk. Microsoft points to General Motors as a company that rebuilt its developer toolchain and its onboarding around this model. The habits that come with it are just as practical. A pool can be set to shut its machines down at a fixed time each day, and hibernation keeps an idle machine cheaper than a running one. So a team isn't paying for desks. Nobody is sitting at.

7:45 What you're really watching is a change in who waits. The developer stops waiting on hardware, and the platform team takes on the setup work instead. How dev Box fits with Microsoft three hundred sixty five and Azure. This is the question that decides whether dev box is something you can pick up or something your company has to run. So let's place it properly. Dev box is an Azure service. The dev Center and the projects are Azure Resources, which means they live inside an Azure subscription and show up on Azure Build. That's the platform engineering side of the house. It leans on Microsoft three. Sixty five as well. Every Devbox user needs one Microsoft Intune license and the Azure subscription and Intune have to sit in the same tenant, which is the shared identity space a company already uses. The detail that catches people is the license math.

8:25 One Intune license covers a developer who creates several dev boxes so a single person can run multiple machines without extra licenses. The work then splits across three roles, and Microsoft is clear about the order. Platform engineers built the dev center, the networks and the images. Team leads create the pools and decide what each team gets. Developers create their own machines and nothing more. The advice from Microsoft is to give everyone the most restrictive role that still lets them do the job. So a team lead who only manages one project doesn't need access to the whole subscription. For anyone wondering how much setup this takes, Microsoft's own checklist runs from configuring the Azure subscription and the networks through creating the dev center and the projects all the way to images and device management.

9:07 It isn't a weekend project. Microsoft also suggests starting small with one team of five to ten developers in a single region and watching it for two to four weeks before rolling it out to everyone. Finally, place Dev Box in the family. It shares its foundation with windows three hundred sixty five, the service that streams a persistent windows desktop from the cloud, and it sits beside Azure Virtual Desktop in Microsoft's Cloud workstation lineup. So the honest answer to where this fits is that dev box is the developer flavored member of a group of cloud PC services. It's a company level tool rather than something an individual signs up for on a Saturday afternoon. The mistakes people make with dev box. Almost every problem with dev box comes from treating it like something it isn't. So here are the ones that show up again and again. The first mistake is expecting a plain virtual machine.

9:50 A dev box is managed and governed. And that's the whole point, which means rules about which images and networks you're allowed to use. If you want total freedom over the hardware, this is the wrong tool for the job. The second is turning on BitLocker. Microsoft says the disk is already encrypted, and enabling BitLocker yourself can leave you locked out of the very machine you were protecting. The third is assuming it's instant. Twenty five minutes or more is normal for provisioning, and on a bad network day, it stretches further. The fourth is ignoring the cost controls. A dev box left running still costs money, so auto stop schedules and hibernation aren't optional extras. They're the difference between a bill you can defend and one you can't explain. The fifth is placing the pool in the wrong region. The network connection decides where that machine sits, and typing lag is the first thing a developer notices.

10:33 So put the pool near the people who will use it. The sixth is planning around a personal account because dev box won't accept one. The seventh is wanting on premises access and expecting the simple setup. The moment a dev box needs to reach corporate systems, firewalls, or custom routing. You have to switch to your own Azure network connection. That's real design work rather than a checkbox. The eighth is for getting the network math. Every dev box needs its own IP address, plus a couple more for health checks and infrastructure. So a subnet that was planned too tightly runs out of room long before it runs out of developers. The ninth is assuming the Linux first crowd will be happy. Devbox runs Windows and Linux. Work happens through Windows Subsystem for Linux, which isn't the same as a native Linux machine. If a team lives in containers and open source tooling, a browser based development environment may suit them better.

11:17 The tenth is assuming windows three point sixty five will be a straight swap. Microsoft says it isn't a one to one replacement, and that decision is the next thing you need to understand. The honest limits, including the one Microsoft just announced. Now for the part no one tells you about Devbox and the reason it matters more than any feature list. Microsoft is retiring Devbox. The service retires at five p m UTC on the eighteenth of September twenty twenty eight, and the closing down period began on the fourteenth of September twenty twenty six. Even earlier than that, Microsoft stopped accepting net new customers on the first of November twenty twenty five, so a team starting fresh today can't simply sign up and begin. That sounds worse than the reality, and Microsoft is fair about it. Existing deployments keep working through the transition, and the guidance is to keep using what you already have as a temporary solution while you plan the move.

12:05 What Microsoft asks you not to do is build new, long lived dependencies on a service that now has a date printed on it. If you already run dev box, the practical first step is an inventory. Microsoft points to the Azure Advisor Service Retirement Workbook, which lists the subscriptions and resources the change affects. The company also asks teams to add their own list of dev centers, projects, pools, network connections, images, and the people who use them. The end is the part to plan around. After retirement, the service is unavailable and remaining workloads are expected to be deleted, so anything a team still needs has to move before the deadline. There's no grace period to lean on afterward. Microsoft's recommended replacement is windows three hundred sixty five, and the company is equally clear that it isn't a one to one replacement. Architecture, licensing, management, networking, image delivery, and self-service can all differ.

12:49 There's no one click migration tool either, so the move is a project rather than a button. The reason for the change is simple once you hear it. Dev box was built on the windows three hundred sixty five foundation. So instead of running a separate developer service, Microsoft folded the developer features into windows three hundred sixty five. That work brought a ready to code windows eleven developer image in preview loaded with Visual Studio code, git, GitHub, CLI, Python, Node.js, and Windows Subsystem for Linux with ubuntu. It also brought thirty two core GPU options for heavy work and a place to run AI agents, so the honest summary comes down to one sentence the product is going away, and the idea it proved is carrying forward what to take away. And a question for you. If you remember one thing from today, remember this dev box is a full windows machine hosted in a Microsoft data center built from a dev center, projects pools and dev boxes managed with Intune and enter ID and reached from whatever device you already own.

13:41 It arrives setup. It can be replaced in minutes when it breaks, and it was retired in favor of windows three hundred sixty five. The name is on its way out even though the idea isn't. So here's my question for you. Has your team ever lost days waiting on a work machine to arrive? And what did you do in the meantime? Tell me in the comments, because those stories are usually better than the marketing. If this made the topic feel less intimidating, subscribe to M365 FM to master the tools and the mindset shaping the future of work.