MSLab: reproducible Hyper-V labs for Azure Local, S2D and Windows Server testing

The problem is a lab that only exists on one machine

MSLab is a GitHub project that aims to provide virtual environments in Hyper-V that can be built in a consistent way. It comes at no additional cost, it is free and available under the MIT License.

The word to hold onto is consistent. A lab that lives on one engineer's laptop is not reproducible, and the use case section spells out why that matters. Many times there was an issue that was hard to reproduce, and even if you could reproduce it, another person did not have the same environment, so with the same steps the issue might not occur again. MSLab changes this, because all environments with the same LabConfig are the same, and the only things you need to share with another person to reproduce an issue are the steps and LabConfig.ps1.

That is the central value proposition, and it is the same value a container image provides in a software project, applied to virtual machines. The audience is Windows infrastructure engineers, architects and trainers, particularly those working on Azure Local, which the repository description names as the formerly Azure Stack HCI, and on Storage Spaces Direct.

Two design choices are stated up front and they explain the rest of the tool. MSLab focuses on simplicity, with all actions done without typing complex scripts, and on a low profile, with all disks differencing, minimum requirements of 8GB RAM and 40GB free space. There is no special hardware requirement, and it can run on almost any machine that has an SSD and a decent amount of memory.

Hydrate once, then deploy in minutes

The workflow has two phases, and the split is the thing to understand before you start.

The first is the Hydration Phase, described in the documentation as the most time consuming step at one to two hours, but something that needs to be done only once. It creates the virtual hard disks from the provided ISO and it creates the Domain Controller. The cost is concentrated in that one step, and it produces a reusable local artefact.

The second is MSLab Deployment, which takes only a few minutes because it just imports the Domain Controller and adds the other virtual machines as specified in LabConfig.ps1. The difference in time is roughly an order of magnitude, and that gap is what makes the tool usable in a classroom or a workshop, where you deploy repeatedly in front of an audience and cannot afford an hour of setup each time.

The disk strategy matters here. Because all disks are differencing, a lab is a set of differences on top of the hydrated base rather than a set of full copies, which is why the tool asks for so little disk space and why cleanup is cheap. The prototype use case says it directly: if something goes wrong, there is nothing easier than just running Cleanup and then Deploy again.

The requirements are correspondingly modest: Windows 10 Pro or Enterprise, since Hyper-V is required, or Windows Server 2016 or 2019, plus 8GB RAM, a CPU with virtualization support, an SSD and 40GB of free space.

LabConfig.ps1 is the entire environment definition

MSLab virtual machines are defined in LabConfig.ps1 as a simple hash table. That is the whole configuration format, and it is the reason the tool is shareable.

Because the environment is a hash table, a configuration can be handed to someone else and produce the same result. The hands-on labs use case puts it plainly: labs are easy to distribute, and once you have done the Hydration Phase you can copy the result folder to multiple computers and deliver an entire class.

The issue reproduction use case is the same property pointed at a different problem. All MSLab environments with the same LabConfig are the same, so the only things you need to share to reproduce an issue are the steps and LabConfig.ps1. A stack of YAML or JSON describing servers and roles would do the same job, but a PowerShell hash table means the person receiving it can also run it.

The repository layout reflects this. There is a `Scripts/` directory with the main scripts, a `Docs/` folder holding the hydration and deployment documentation, `Tools/`, a `build.ps1` at the root, `Scenarios/` for the older scenario library, and `HandsOnLabs/` for the current guided material.

The scripts come as a release ZIP, not from the repository

How you get the scripts is unusual enough to be worth a paragraph, because it affects how you upgrade.

In the past, the ZIP file was stored in the git repository. Recently the project switched to using the native Releases feature of GitHub, where all releases are available on the releases page of the repository. There is also a static direct link to the latest MSLab release on `http://aka.ms/mslab/download`, which is updated automatically when a new version is created. The readme's summary is that to start using MSLab you download the latest version of the scripts from the Releases page, or start with HandsOnLabs.

The reason for the change is not only tidiness. The built ZIP file is more optimized: the file `0_Shared.ps1` is in-lined into the rest of the scripts to keep the number of MSLab files as low as possible, compared to the git repository where the scripts are split into multiple independent files for better maintainability on the maintainer's side. In other words, the repository is for the people who change the scripts, and the release ZIP is for the people who run them, and the two are deliberately shaped differently.

There is a data collection section as well, and it is worth reading. The software may collect information about you and your use of the software and send it to Microsoft, Microsoft may use it to provide services and improve its products, and you may turn off the telemetry as described in the repository. The readme also notes that your use of the software operates as your consent to those practices.

Hands-on labs are current, the scenarios folder is not

The repository carries two bodies of material, and the readme is candid about the difference.

The current one is Hands-on Labs. The history is that the author originally developed Hands-on Labs while working for Dell on the AzureStackHOLs repository, and to continue with just virtual labs, MSLab hands-on labs are now being added. The list is six entries: creating your first lab, deploying Azure Local, a rack level nested mirror S2D cluster marked Insider Preview, a volumes deep dive, simplified machine provisioning, and testing Windows Server Insider Preview.

The older one is the Scenarios folder, which the readme says contains multiple scenarios simulating Azure Stack HCI and deep dives into other technologies such as Windows Admin Center, Certification Authority, and BitLocker with Just Enough Administration. The readme also says scenarios can be reused for real environments, giving S2D Hyperconverged as an example that can be used to deploy real Azure Stack HCI clusters.

Then the caveat, which is important: the Scenarios material has not been updated for quite some time, because the effort went into the Dell Azure Local hands-on labs, and the readme says to consider it just an inspiration. The scenarios are a source of ideas and a set of configurations, not a maintained product.

The distinction also tells you what has been renamed. The repository description now says Azure Local, formerly Azure Stack HCI, so the tooling has followed the product renaming.

Where MSLab is the wrong tool

Four limits are clear.

The first is platform. Hyper-V is required, so this runs on Windows with hardware virtualisation enabled, and the requirements name Windows 10 Pro or Enterprise or Windows Server 2016 or 2019. There is no Linux host path in the requirements, and while the readme's table of contents includes a Linux preview section, a preview is not a deployment target for a training environment. A team on macOS or on a Linux CI runner is looking at a different tool.

The second is what the lab can be. MSLab builds virtual machines. It does not reproduce physical hardware behaviour, kernel or firmware faults, storage controller quirks or a specific network device, and because every disk is a differencing disk, a lab can be reset by cleaning up and deploying again. A lab that is reset is a feature for teaching and a limitation for investigation.

The third is that it is a scripting tool, not a product. There is no installer, no GUI and no service to run. The value is in the scripts and in the LabConfig format, so adopting it means adopting a directory of PowerShell that you will be reading and editing, and the repository's own guidance is to consult the documentation for configuration, installation requirements, provider setup and deployment.

The fourth is the archived material, already mentioned: if your plan depends on a scenario in the Scenarios folder, verify it still works, because the project says it has not been updated for some time.

On maintenance and licence, the record is healthy. v26.05.1 was published on 2026-05-15, v26.06.1 on 2026-06-03, and v26.07.1 on 2026-07-30, with the last push to the repository on 2026-08-10. The licence is MIT, with the file named `License` at the repository root, and the repository also carries `SECURITY.md` and a `Contributing.md`.

Editorial conclusion

MSLab fits a Windows engineer who needs a repeatable multi-machine environment for a course, a conference demo, or a bug that only reproduces on a specific topology, and it fits a team that wants to hand every attendee the same lab. It does not fit anyone without Hyper-V, since the whole design is built on Windows virtualisation with differencing disks, and it is the wrong tool for reproducing a physical hardware fault. Before you rely on it, read the Scenarios folder with the caveat the project itself gives, that those scenarios have not been updated for some time, and check the telemetry setting described in the repository before running it on a shared machine.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. microsoft/MSLab on GitHub
4. README
5. Releases