Recovering student's Lab machine

Occasional Contributor

Hi All, 


Our organization is using Azure Lab Services and, we are seeking advice on a problem we are facing. 


The problem happens when students mistakenly modify the connection of their Lab machine. Understandably, changing the IP setting makes the RDP string obsolete. After that, the VM takes like 45 minutes to start (sometimes it fails and stops immediately) and, if it starts, the remote desktop is not possible.


Of course, we can reset the bad VM but, that is not convenient because they will lose all their work.


My questions are: 


  • Is there absolutely no other way to access a machine that its initial IP address has changed? 
  • Is there any way to backup students' lab computers? 




5 Replies
Could you explain a little more about how the student is changing the RDP setting? Are they manually changing the IP from the OS using the network adapter?

As explained in, Azure Lab Services uses a load balancer to map {public-ip-for-lab}:{random-port} to {student-vm-private-ip}:3389. You could try logging into the rogue lab VM from template VM using the private ip of the rogue lab VM and reset the private ip back to what ALS expects it to be. You'll need to get the current private ip, username, password from the student. You can get the private ip that Azure Lab Services expects by looking at the 'Virtual machine pool' page for the lab.

As far as backing up student's computer, there are several possibilities for backing up the data, so resetting the VM isn't cause for losing all their data. talks about how to configure OneDrive for the student. covers some options for external storage which is useful for classes that require large amounts of data.

Hope that helps,

Hi Elizabeth,

Our lab exercises involve IP, DNS, and DHCP configuration. We use nested virtualization with Hyper-V.

However, sometimes, students don't release which machine they are working on and run the configurations on their Azure lab machine and that breaks things.


Your solution suggested we "reset the private IP back to what ALS expects".  That partially works. Sometimes students don't know the new Private IP that they have assigned, which makes the Remote Desktop connection using the Private IP impossible. 


I'm using this module to see the lab information. I'm wondering if any of the parameters below could be used to access the virtual machine? 

Screenshot 2022-03-09 at 10.13.07.jpg

Another question is, why Lab Services' virtual machines don't show with regular Get-AzVm command? 


There is also no network information, why is that?


I assume these are by design and for security reasons, but could someone please confirm if there is no way around this? 







My apologies for the delayed response.


After a student VM is reset, they should be able to connect using the 'connect' button.  (The connect button uses the public IP address.)  If this is not the case, then this is a product issue I should log with the team.


There are two ways to get the private IP address of a student VM if you want.  The Azure Lab Services virtual machine pool page shows private IP addresses for student VMs.  (Export list of VMs in Azure Lab Services | Microsoft Docs) The other option is to use the PowerShell module you referred to.  The cmdlet that will show rdp info and private IP address is 'Get-AzLabStudentVM'.

Get-AzLabAccount -ResourceGroupName MyResourceGroup -LabAccountName MyLabAccount | Get-AzLab -LabName MyLab | Get-AzLabStudentVm


Does that help?  Please let me know if you are still having issues.






thank you for your reply.

The reset works fine. But my entire effort is to avoid using it because all the work on that machine will be lost. (details mentioned above)

The two ways that you recommend for checking the private IP works only if the private IP hasn't been changed. If the private IP changes, because of the reason I explained earlier, the labs front end and PowerShell both still show the initial IP, not the new one.
best response confirmed by Masih17 (Occasional Contributor)


There aren't any options for you to fix this as you don't have access to the underlying Azure resources (vms, etc).  You could create a support ticket to see if the engineering team has any options to help you out.