Photo by @aaronburden /

Building the perfect remote workstation in the cloud

Thanks for reading my blog! If you have any questions or need a second opinion with anything Microsoft Azure or Power Platform related, don't hesitate to contact me. I'm happy to provide my professional services through my company, North Advisors.

I’ve worked remotely from 1997, or so. Back then, remote work was considered “working overtime in the evening” and I would do my regular 40 hours at the office, plus whatever on top by working remotely. Later, I worked on-and-off remote. For the past few years, I’ve worked more or less fully remotely from home. The occasional office visit and customer visit are obviously still there, but a physical desk waiting for me at the office hasn’t been the norm for me in years.

One aspect that the public clouds – Microsoft Azure, AWS and Google Cloud Platform – brought us, is superior tools for productivity work. And as much as I love using instant messaging, intranets, email and other tools the main thing I need is a solid workstation.

I set out to built the perfect dream remote workstation in the cloud. Here’s how that turned out.

Laying out the basics

I’m using Microsoft Azure to build my remote workstation. With Azure, one of the upsides is that there are plenty of services I can choose from. Obviously, this might also be confusing, as you often have several services that provide a similar service.

As my dream remote workstation will be a virtual machine, I have the following services I can leverage to achieve my goal:

I chose to build my environment using Azure DevTest Labs. It’s ideal for provisioning VMs, and it allows me to configure and control them without much effort. In a way, DevTest Labs provisions a regular VM but it gives me added control and governance over it.

Creating and configuring Azure DevTest Labs

First, I’ll create a resource group to hold my resources. I’m using Azure CLI for this part, although you can use Azure Portal as well. If you’re not familiar with Azure CLI, see my quickstart guide here.

az group create --resource-group "dreamstation" --location westeurope

Next, as this is a one-time thing, I’m using Azure Portal to provision the DevTest Labs environment. You could use Azure CLI for this, but it’s a bit too complicated to justify spending so much time on it in the command-line.

Click the + icon in the portal, and search for DevTest Labs:

Select DevTest Labs and then click Create.

Fill out the details on the creation blade.

I chose to enable Auto-shutdown so that all my lab VMs will automatically turn off at 5 pm.

Once provisioning is complete, you can start configuring DevTest Labs and adding your own VMs.

Formulas allow you to create pre-defined bases for your VMs. Start by searching for your desired base OS image – for me, that’s Windows 10.

I’m choosing Windows 10 Enterprise multi-session, Version 1909 + Office 365 ProPlus, as it provides me with the latest stable bits together with Office 365 ProPlus. I can then define credentials, as well as the VM size. As I’m not planning to run this VM every day, I’m opting for speed – DS3_v2 is great for that. It has 4 vCPUs, 14 GB of RAM and plenty of IOPS (12800).

And finally, I’m adding a few useful artifacts – pre-defined software for the VM!

Some of the artifacts I choose include Notepad++, 7-Zip, latest Windows Updates, and a few Chocolatey packages (Microsoft Edge, especially).

Creating the remote workstation

Click the + sign within DevTest Labs, and select your custom base.

You’ll notice that creation takes a while and that the VM is not automatically set for Auto-start:

Applying artifacts:

Once provisioning is complete, you can RDP into the VM. All the artifacts are also now deployed:

Configuring network security for DevTest Labs

As you might have noticed, the default virtual network setup for DevTest Labs allows for Remote Desktop access to anyone. Granted, the default port is changed, but it’s still wide open. It’s a great idea to add a little bit of security here, by adding a new Network Security Group for the VNET.

You can do this easily by provisioning a new NSG, and then binding that to the VNET your DevTest Labs VM is using. Finally, add an inbound security rule that allows you to connect with the VM.

In summary

DevTest Labs adds an easy way to provision VMs with pre-defined configurations. While auto-shutdown (and auto-start) are great for cost management, DevTest Labs also has a convenient way to set cost targets, and what happens when the target is reached.

DevTest Labs is free, but all resources including VMs, storage and egress traffic is billed as usual.