Earlier today, Microsoft released DevBox into Public Preview (which is a feature that was announced at Microsoft build earlier this summer. Microsoft DevBox can be seen as an alternative to Windows 365 and Azure Virtual Desktop but is aimed at Developers, as it is still about providing developers with a VDI desktop in Azure running their software development stack.
You can see this by just seeing the resource underneath and also the references in Azure Monitor when deploying the resources
From an operations perspective, it is a combination of the Windows 365 front-end portal (https://devbox.microsoft.com/) where Developers gain access to a self-service front-end to their virtual machines, and the RDS components of Azure Virtual Desktop, which means that it is running much of the same core components underneath.
Now to set it up you need to understand some of the core concepts of the service.
You first have a resource called DevCenter which is a logical container for all other resources in DevBox. The DevCenter contains Network Connections which are essentially two things 1: VNET Integration 2: Machine configuration if it is either domain joined or Azure AD joined.
Within a DevCenter you can have one more multiple network connections. Then you have DevBox definitions which contains built-in Microsoft Images where you define the size of the machines. Lastly is compute galleries which can contain your custom images.
Then you can group together a Network Connection with a DevBox definition or Compute Gallery which are grouped together into a DevBox Pool which is deployed into a Project.
So can have a project which contains multiple DevBox Pools that can be grouped together into a single project.
NOTE: Before setting up the service you might encounter some issues with deployment, if so you need to register a new resource provider (EDIT: Has been fixed by Microsoft: Issue with provisioning network connection · Issue #97119 · MicrosoftDocs/azure-docs (github.com))
az provider register --namespace Microsoft.DevCenter
First we need to create the DevCenter Resource.
Here we have some different options that we need to configure to make this work
- Networking Connections
- DevBox definitions or Azure compute Galleries
Then we can create DevBox Definition using built-in images. Here we can define the Compute and images to use from the Microsoft Gallery.
Then we need to create a Network Connection, where we define which virtual network we should use and what kind of domain join we should have for resources that will be using this network connection.
Then once this is done provisioning we need to attach the network connection to the DevCenter resource. Once you add a network connection, Microsoft will do some healthchecks to ensure that it working as intended.
Now we have a Dev Box Definition and Network Connection the last part we need to do is create a project which will use both of those. Create a project and within the project resource click on create a dev box pool.
Here we define a name, privileges (local user or admin) then Dev Box definition and network connections.
Once this Dev Box pool is created (which can take some time) you need to assign permissions to the Project or else users will be seeing this error message once they try and access the end-user portal.
On the project level you can assign either Dev Box User or Project Admin permissions. Assigning Dev Box User will allow the developers to setup their own machine using the web portal.
Once the Dev Box role permissions are assigned, the users can access the portal on https://devbox.microsoft.com/
So far being a preview it seems to be pretty solid and I like the way that they design the product, however there are some caveats that I would like for them to approve.
- I would like to define compute SKUs myself and not be bound to the resources that Microsoft have defined, so it means that I’m bound to what Microsoft is showing in the Dev Box definition feature.
- GitHub CodeSpaces should also be a part of this or atleast as an alternative feature.