Experimenting with Azure Virtual Machines Part 1 – Azure Lab Services


Since I’ve moved on from Microsoft, my interests and focus have expanded beyond just the realm of Microsoft365 offerings and I’m dabbling in other technologies that can add value to the education industry and beyond.

In this multi-part blog series, I’m going to explore different flavours of Azure Virtual Machines, so buckle up and enjoy:

The Case For Azure Lab Services

Azure Lab Services enable you to easily set up a class, run a training lab, host a hackathon, experiment, and test your proof-of-concept ideas in the cloud.

Azure Lab Services

Configuring a traditional computer lab for specific scenarios has historically been a time consuming process. This has been made easier with the advent of cloud MDM tools like Microsoft Intune which can offer a significant amount of customized experience based on the user signing into the device, however there are still many scenarios that exist where greater levels of customisation are needed (Note: it is possible to use Intune to manage your Azure Lab Services too).

Furthermore, the end users may be bringing their own device (BYOD) that is not compatible or powerful enough for the task at hand – cloud based virtual computer labs provides a very real solution to this situation. In fact, recently I was talking with a school that was in this exact situation – students were using iPad Pros but required a Windows device for a particular online test. The ability to provision virtual machines for short term usage for students for the test was one avenue the school explored.

Other scenarios that Microsoft has created specific ‘how to’ tutorials for Azure Lab Services include:

In a business context, the ability to run training for staff in a contained environment that can be easily re-deployed for different groups of staff is very appealing. Likewise, if you’re conducting UX/UI testing with control groups, having the ability to run repeatable testing in a pre-configured environment is helpful.

Creating An Azure Lab Service

Rather than reinvent the wheel, I’ve embedded a good 3minute video from Microsoft showing the basics for setting up an Azure Lab. Note that the video is 2yrs old and there are some subtle differences to the Azure Portal now, but fundamentally the process is the same.

If you’re more of a ‘step by step’ learner, then the overarching process is as follows:

  • Create a Lab Plan
    • The Lab Plan is basically a collection of configurations and settings that apply to any labs created inside it. This includes linking it to an active Azure subscription, resource group for management and also the Azure region where the lab VM’s will be deployed.
  • Add a user to the Lab Creator Role
    • This allows you to choose who in your organisation can create new labs under the current Lab Plan.
    • Note: given all labs will incur costs, you want to be clear about who is responsible for associated billing costs that come from the lab usage.
  • Create a Lab
    • This is where you configure and create the actual VMs. It differs from the Lab Plan (high level configurations and settings) as it focuses much more on the type of VM you’re wanting in your Lab (OS, RAM, CPU, policies etc)
    • Note: initially you create a generic username/password to log into the VM. You have a choice to lock the password or allow the end users to reset the password on first login.
    • Customise the VM: You have a choice of running a standard OS template (choices around Linux, Windows 11, Windows Server etc) or choosing to customise a template with your specific needs.
      • Essentially, you start the custom template VM, make changes (install required software, make settings changes etc), stop the VM, then publish the custom VM template to the Lab. Details are here.
  • Publish Lab
    • This process allows you to choose/define the maximum number of VM that will be available to your end users. It’s super easy and the time to access the VMs depends on the number you’re creating.
    • Note: due to Azure region capacities, I have found the ability to create VMs is limited at times – the Azure Lab Services wizard advises how many VMs you can create in the current region during the Publish Lab process.

It really is that simple of a process and with the Lab created, the dashboard does give you an indicative cost associated with the lab. For experimentation purposes, I created a Lab with 5 VM that had a maximum of 10hrs per VM (so 50hrs total) and the indicative cost was USD$10 if all hours were used:

Shortly, I’ll share some tips on how to manage billing by implementing some guardrails around usage and avoiding cost blowouts.

Connect To A Lab

Once a lab is created and published, the ability to connect to each of the individual VM can be managed in a few ways, either by assigning VM to a specific student (AzureAD group sync or CSV upload), sharing a self-registration link, or emailing an invite to users. Once received, they can start the VM and connect to it using the RDP client of their choice. Either the Lab owner or the student can start the VM and then the remote desktop connection file can be downloaded and used to launch the remote desktop client to connect:

The student would need to sign in at the Azure Labs Portal with their organisational AzureAD credentials and they need to know the initial VM username/password created above (and, if configured, may be prompted to reset the password on first sign in).

Alternatively, if comfortable, a host and port number can be shared with an end user directly from the Lab VM pool page e.g.

Here is the same VM connected to using the Microsoft RDP client on my MacBook:

The Azure Lab Services dashboard allows you to see at a glance which machines are on, and how many hours of their assigned quota have been used:

With the appropriate permissions, a Lab Creator can start, stop or reset any of the VM in the lab. An individual student can turn on/off any VM in a lab that has been assigned to them through the portal.

Managing Costs – Avoiding Budget Blowouts!

Microsoft does publish a pricing calculator table online here.

One of the biggest considerations and concerns from organisations new to Azure Virtual Machines is the issue of cost and more specifically, how to avoid unpleasant bills for un-budgeted consumption! There is detailed guidance that you can read here

The good news is that Azure Lab Services offers three main ways to manage costs.

Quota Hours

The simplest way to have as close to a ‘fixed’ maximum cost as possible is the requirement to define the number of hours quota to the VM at the time of the lab creation. In my example above, I created 5 VM for a maximum of 10hrs per VM, that would have a total approximate budget of USD$10.

There are two variables that affect this cost: if students use less than the maximum quota of hours and the VM is turned off then the cost will be lower. More importantly, if the Lab Creator (professor, assistant, trainer etc) go into the VM to assess student work, then there is a charge for the consumed resources during these activities above and beyond any student consumption (and also above the quota hours)

Quotas are a good way to allow students to work on the VM for homework outside of scheduled class hours.


Scheduling creates either a one off or recurring schedule that will automatically start the VM at the define time (ahead of class, for example, to save time wasted on waiting for VM to start manually)

Note: scheduled hours and quota hours can operate separately or together. From the Microsoft Docs:

The use of schedules for a lab is optional and you might specify user quota instead, or use a combination of both. User quota is the time that lab users can run their lab VM outside of scheduled time. For example, to complete assignments or homework. Any scheduled time doesn’t count against extra time that lab users have. A lab can use quota time, scheduled time, or a combination of both.


You can set a schedule to implement a hard stop on usage of VMs (e.g. end of the school/business day) that helps with ensuring no VM is left on accidentally creating wasted expense.


Put simply, these are ways to automatically shut down the VM if there is no active usage or no user connects to the VM once it starts. The options are as follows:

Whilst turning off a VM based on idle time makes a lot of sense to avoid unnecessary costs, getting this setting right may depend on your scenarios – some forethought into an appropriate ‘timeout’ period would be beneficial to avoid frustration of a user getting logged out and having to restart their VM.

A key takeaway for me is that there are various mechanisms that can be put in place to provide assurance around costs and prevent unexpected bills for the use of Azure Lab Services

Final Thoughts

Azure Lab Services offers affordable, flexible virtual machines in a lab context for a variety of services. It’s quick and easy to deploy and, if desired, the VM can even be managed by your Intune MDM licensing.

Given many educational institutions use iPads or ChromeBooks, Azure Lab Services can provide an ‘on demand’ virtual Windows lab that can be easily connected to from any OS. This can go some way towards delivering a more equitable device experience by removing the limitations of the host device a student may use by supplementing it with a virtual desktop that has comparable specifications for all students in a class.

I certainly look forward to having more conversations with customers about scenarios were Azure Lab Services would be of benefit to them.

I am always keen to discuss what I've written and hear your ideas so leave a reply here...

%d bloggers like this: