Tips on getting started with Microsoft Dev Box during public preview

From Monday 15 August 2022 anyone can now try out Microsoft Dev Box through it entering public preview. It's a service that offers a lot of potential, but during preview there are a few moving pieces you need in place to try it out and maximise your benefit.

Note that this post only covers the service during public preview, and as with any preview service, things are likely change. I'll keep this post updated as more elements ship or are locked in for General Availability. Feel free to drop any questions in the comments section below.

Tip List

The Microsoft Docs page for Dev Box does a great job of getting you up and running, but it makes some assumptions about your current setup. Here I'll cover things to be aware of.

A lot of the foundational pieces for Dev Box will need support from your IT Ops team as they will be required to configure the underlying Microsoft infrastructure that is needed before you can even create a single Dev Box instance. If your business is already using Windows 365 or Azure Virtual Desktop, then some components will feel familiar.

Active Azure Subscription

This one is probably an obvious one, but I'll put it here anyway. Today there isn't a way to create any of the Dev Box service without already having an active Azure Subscription.

Use recommended Remote Desktop (RDP) clients

The best bet to make the Dev Box experience work for your team or developers is to use one of the Microsoft-recommended clients which are listed on Microsoft Docs.

If there is no native client for your OS, then the web client works really well.

Azure Active Directory / Active Directory access

When you create a new Network Connection for the Dev Center that will host your Dev Boxes you need to select how new Dev Box instances will be managed in your organisation. If you are already using Azure and are comfortable with using Azure AD I'd recommend that. If you don't use Azure AD for device enrolment / management you will need direct access to an Active Directory instance and an account in that Directory that can be used to domain join new Dev Box machines as they are created.

If you're a cloud-only business, then Azure AD is the way to go.

Windows 365 knowledge will help

If Windows 365 is not a technology you are familiar with, I'd highly recommend watching the Microsoft Mechanics episode on creating and configuring Windows 365. This will give you (or the team responsible) an idea of how the core of Microsoft Dev Box functions and how / why you need to configure items such as network connections and directory access.

Microsoft Endpoint Manager (Intune) policies can affect Dev Boxes

You do need to be aware of how your business has configured Microsoft Endpoint Manager (MEM) to manage Windows devices. Any configured policies may cause Dev Box provisioning or functionality to fail or not work as expected. If you aren't using MEM to manage Windows devices (or you're not using MEM at all) then this doesn't apply to you.

The warning link helpfully links out the documentation relating to Windows enrollment with Intune. Even though I received this warning the Dev Box still provisioned fine and I was able to use it as expected.

Windows 10 hosted client licenses

From the official FAQ for Dev Box:

"Which licenses do I need to use Dev Box?

To use Dev Box, each user must be licensed for Windows 11 Enterprise or Windows 10 Enterprise, Microsoft Endpoint Manager, and Azure Active Directory P1. In addition to being available independently, these licenses are included in Microsoft 365 F3, Microsoft 365 E3, Microsoft 365 E5, Microsoft 365 A3, Microsoft 365 A5, Microsoft 365 Business Premium, and Microsoft 365 Education Student Use Benefit subscriptions."

Today there is no on-demand facility for Windows 10/11 client licensing in Azure, so you will need appropriate existing Windows client licensing to use Dev Box. This is typically used for Azure Virtual Desktop or as part of certain Microsoft 365 or Windows 365 subscriptions. You can find more details on Microsoft Docs on the document "How to deploy Windows 10 on Azure" (this also applies to Windows 11).

It's important to note that this isn't the same as simply buying a Windows 10 or 11 license you can use on a PC in your office.

Custom Machine Images

Once you have all the pieces in place it's quite simple to start a new Dev Box - head to the Dev Box portal at https://devbox.microsoft.com/ and log in with credentials that have been assigned the Dev Box User permissions in Azure Active Directory (see documentation).

The real power, however, will come with the use of custom machine images that can be pre-configured with all the software and configuration information required for a developer to be productive.

The Dev Box team is working on a streamlined service to produce custom machine images, but in the meantime you'll need to use either an uploaded image (VHD / VHDX) into Azure or capture a running Azure Virtual Machine as per the Microsoft Docs or community sites (you can skip the component on adding the image to Microsoft Endpoint Manager).

If you've never built Windows machine images before you should be aware that many pieces of software (for example, SQL Server) don't function correctly after a machine has been "generalised", so you need to automate the installation of these components once a new instance is created from the generalised image. At present the way you will need do this is by using the Microsoft Endpoint Manager's management extension to deploy and run PowerShell Scripts.

Wrapping up

This post is really designed as a brain dump I've captured while working with the service in preview. If you have questions or other items you think should be included please drop them below in the comments.