Getting started with Microsoft Dev Box

As businesses transition to hybrid work, it’s becoming harder for IT departments to manage and control PCs. When there’s no way to manage and control the network a PC is on, how can you be sure that its data is secure?

Microsoft’s Windows 365 Cloud PC concept is intended to bridge that gap, letting users continue to work in their PCs with workloads and data stored in Microsoft 365 and Azure. Applications can be provisioned and maintained using familiar tools and delivered to user desktops via Remote Desktop.

That same approach can be used for more than task and information workers, taking advantage of the compute capabilities of the cloud to run complete developer environments. While security issues remain important, there’s another aspect of the Cloud PC that can help developers: Supply chain issues make it hard to source the high-end hardware needed to build modern applications — especially ones that depend on GPUs for machine learning or scientific computing.

SEE: Google Workspace vs. Microsoft 365: A side-by-side analysis w/checklist (TechRepublic Premium)

Instead of building and running your development toolchain on your desk, why not host it in the cloud, accessing it on PCs, on tablets and even on a phone. These capabilities are available to preview through Microsoft Dev Box.

Announced at BUILD 2022, Dev Boxes are now in public preview, giving you the opportunity to try them out before committing to using them in your development teams. The preview gives you an opportunity to experiment with different custom images, alongside Microsoft’s own Cloud PC systems.

How to configure your first Dev Box

Dev Boxes are managed through a DevCenter hosted in Azure. Start by creating a DevCenter from the Azure Portal, assigning it to a subscription and a resource group, as well as a deployment region. Once you’ve named and created your DevCenter you can manage it using familiar Azure tools.

There are three management options: Defining your Dev Boxes, configuring virtual networks, and using projects to group configurations and networks, along with other resources. What’s important is that you can build entire development infrastructures in Azure, so your developers can code, build and test their code from their Dev Boxes without needing any additional resources.

Define the Dev Box and choose an image

Defining a Dev Box is the first step. Next you need to give it a name before choosing a base image. Currently the service preview offers Windows 11 and Windows 10 images based on the Enterprise SKU. Releases are available with and without Microsoft 365 apps, going back to Windows 10 1909. This approach allows you to target appropriate Windows versions as well as fitting in with your own support and management decisions.

Adding Microsoft 365 support to an image will allow developers to make it their default work environment, though some may prefer to keep development and productivity tools separate. However, including tools like Word and OneNote can help ensure projects are properly documented.

Each image will be versioned, though while the service is in preview you have the option of 1.0 and Latest. Next you can choose the underlying virtual machine that hosts the Dev box environment. In the preview, this is limited to 4 or 8 vCPUs and 16 or 32GB of RAM.

Finally, you can pick storage, 256GB, 512GB or 1TB of SSD. Once you’ve selected the options you will have a base image for your Dev Box. Accounts can have pools of different images and configurations, allowing you to assign appropriate resources to developers. Someone building machine learning code will need a very different set up from someone building JavaScript front ends in Visual Studio Code.

As well as using the default images, if you have an appropriate license, you can build your own custom images and connect the service to an Azure Compute Gallery that hosts them.

Connect the Dev Box to Azure and create Projects

You can now connect your Dev Box service to an existing Azure virtual network, before setting up a link to your Azure Active Directory. This is how you manage and control access, setting permissions for users to use and create Dev Box instances. New networks are automatically tested before you can use them. You may need to open some ports in the Azure firewall to allow access to remote users.

You’re now able to start creating Projects, which manage the instances available to developers and control who has access and what they can do. Projects host pools of managed Dev Boxes, using your existing definitions and network connections. Once you’ve created a pool you can apply the privileges users get, with the option of giving local admin access or running as a standard user.

SEE: Windows, Linux and Mac commands everyone needs to know (free PDF) (TechRepublic)

Next, apply access control rules to a pool, assigning Dev Box User roles to users. You can give access to individual users or whole teams. This lets your users manage and create Dev Boxes, using a self-service portal. Some users can be assigned administration roles, giving them the ability to manage a pool without needing a higher-level admin.

Connecting users to a Dev Box

Once you’re ready to give users access to their Dev Boxes, give them the URL for the Dev Box portal. They’ll need to log in with a work account and will be shown existing Dev Boxes they’re using as well as an option to create a new one. Here they can name it, choose a project and then an instance from an available pool that’s part of the project. Much like a Windows 365 Cloud PC, this kicks off a 30 to 90-minute creation process.

With a Dev Box ready to use, you can access it from the portal in your browser or through a Remote Desktop client. Your Dev Box and files can be paused between sessions and deleted when no longer needed. While browser access is useful for quickly checking some code or making urgent changes, the best experience comes with a native Remote Desktop client, with the portal providing instructions on how to download an appropriate version along with the URL needed to access your Dev Box portal.

It’s not surprising to see Dev Boxes listed as Cloud PCs in Remote Desktop, as that’s what they are. Unlike the standard Cloud PCs, they have more memory, more processors and more storage — exactly what you want from a developer workstation.

How to build custom images

Users will need to install their own toolchain to start writing code, which may slow down initial adoption. However, there is an alternative: Using an attached Azure Compute Gallery to host your own custom images loaded with development applications.

Each image in a gallery can be configured to support specific development teams, with separate images for web, for .NET, for Java and more. A custom image can include libraries and SDKs alongside development tools, ready for a developer to pick up and start coding. Custom images aren’t limited to one project, they can be used across different projects and teams.

Dev Box preview pricing

Dev Boxes are still in preview, with free time for both compute and storage. Once you’ve exhausted your free time, computes are charged at $0.99/hour for 4vCPU systems and $1.98 per hour for 8vCPUs while a system is in use.

Storage comes in at $0.053/hour for 256GB, $0.105 for 512GB and $0.21 for 1TB. Storage is billed even when systems are turned off. Each user will need an appropriate Microsoft 365 license for the OS and Azure Active Directory, along with any application licenses.

Dev Boxes offer extensibility and control

Microsoft’s approach to virtual development is an interesting one. By building on its Cloud PC concept, it’s giving you the flexibility to deliver pre-configured toolchains in a way that still allows developers to add their own favorite tools and plug-ins while still ensuring you can control and secure their Dev Boxes. Similarly, integrating their environment with the entire Azure platform means you’re in a position to quickly go from code to production, especially when working with cloud native platforms like Kubernetes or Azure Functions.