AutomatedLab: two requirements, a dozen prerequisites, and links that point at master

Two requirements in the summary, a dozen in the list

The project summary makes a clean promise: two things to sort out, the DVD images for whatever you are deploying and either a Hyper-V host or an Azure subscription. Then the requirements section runs to about a dozen lines. A management framework version, a .NET version for either of the two PowerShell editions, a host operating system, a recommended interface language, administrator rights on Windows, the images themselves, hardware virtualisation support, memory, and storage. The storage line is the one worth pausing on, because it is the only requirement given as a warning rather than a threshold: low-latency, high-throughput storage, no spinning disks please, as there are issues related to them. A lab framework that fails on slow disks is telling you something useful, and it is telling you in the requirements list rather than in a support article.

The description lists products the supported list does not

The repository description says the project supports Windows operating systems from 2008 R2 to 2022 and products like directory services, Exchange, a public key infrastructure and a web server. The supported-products list covers directory services only by implication, through a sample of three trusting forests, and it does cover Exchange. It does not list a public key infrastructure product and it does not list a web server at all. The operating system claim needs the same care. The list of deployable guests does start at 2008 R2 and includes Windows 7, while the host requirement is a server from 2012 R2 or a client from 8.1. So the description's phrase covers guests and hosts in one breath, and the two are different floors. Within the list the support is also uneven: SQL Server runs to 2022 while Exchange and Office stop at 2019 and Visual Studio stops at 2015.

Linux on Azure is the only combination that works

One sentence under the Azure bullet settles the scope: at the moment the project only works using Azure when using Linux. Everything else about the Azure path is for Windows guests, and the hypervisor support beyond Hyper-V is a plan rather than a feature, with KVM named as later work by virtue of a library. The Linux host list is short: Fedora, Ubuntu, Ubuntu under WSL and the cloud shell, plus Proxmox named as a host option. The guest list adds a caution that will cost somebody an afternoon, the Ubuntu desktop image is not supported, only server. And the framing sentence is the honest one: because Linux distributions are fragmented, support is best-effort and takes time, with regular testing on Fedora outside WSL and on Ubuntu inside it.

macOS support is written as a sponsorship appeal

The macOS line appears twice and both times the reason is that the two maintainers named in the document do not have Apple hardware. The first mention calls it best-effort support since neither of those two people has an Apple device. The second, in the Linux and macOS section, says the same thing and then adds a parenthetical asking readers to feel free to sponsor two. It is an unusual line to find in a requirements list, and it is in the same document that has exactly one sponsor, a paragraph praising a Windows package manager for its public binary gallery, its self-hosted options and its enterprise support. The sponsor text is also the only place a certificate authority appears as a suggested starting point, along with a domain controller, and the sample laboratories it points at are a private gallery and a pipeline lab.

Remoting is mandatory and the fallback advice is hedged

On Linux the one requirement that cannot be worked around is remoting: either SSH or a pluggable authentication mechanism for NTLM, and the text is emphatic that without remoting there is no way for the tool to do its thing. The suggested fallback for anyone who is unsure is to install a PowerShell Web-based management module and then install the management service, immediately followed by the phrase that no success is warranted. That is a rare kind of sentence in a requirements document. Two more requirements read as ordinary but are worth naming: IP and route commands have to be available, which matters on a host where the tool has to create networks as well as machines, and PowerShell Core 6 or newer, which is the edition floor for everything that is not Windows PowerShell.

Credential delegation is on by default and called a convenience

The command that runs your own script or script block across a set of lab machines is documented with its authentication behaviour as a feature. The text says you do not have to think about credentials or double-hop authentication because a particular Windows credential delegation provider is always enabled, and that a switch is provided to use it. The framing is convenience, and inside a disposable lab it is a reasonable trade, since the alternative is maintaining credentials on every machine. It is still the sentence to read twice before the lab stops being disposable, because the property being enabled is the one that forwards credentials on a second network hop. The same bullet also notes that software installation can run in parallel through the PowerShell workflow engine once the silent-install switch is known. The rest of the command surface follows the same pattern of one cmdlet per chore: create, restore and remove snapshots of some or all lab machines with three cmdlets, install Windows features on one, some or all machines with one line, and connect a cloud lab to an on-premises one with a single command.

The default branch is develop and the sample links say master

The repository's default branch is the development one, and the build table at the top of the document has a row for each branch pointing at the same continuous-integration project. The development row has three cells where the release row has four, since there is no release to point at for work in progress. Then the feature list links to sample scripts through paths that contain the other branch name, so the one-machine example and the hundred-line complex example are read from the release branch while the code they describe is developed on the other. The releases themselves move quickly: three patch releases in six weeks at a version numbered in the low sixties of the fifth series, and the newest release carries the same timestamp as the last recorded commit. The tree explains what ships with the module: a solution file and about a dozen project directories for the core, the definition layer, the worker and unattended paths, notifications and a shared project, an installer directory, a directory of sample laboratories and another of lab definitions, a help directory with a script for regenerating it, and a project dedicated to script analysis settings. Documentation is built with a static site generator and hosted, and the repository carries submodule configuration.

Editorial conclusion

AutomatedLab earns its place if you build throwaway directory, certificate and SQL estates on Hyper-V or Azure and have stopped enjoying doing it by hand, because the cmdlet surface is small, the sample scripts are real, and the project documents the parts that hurt rather than skipping them. Three things to weigh. Azure works with Linux only, and everything else about Linux is best-effort by the maintainers' own admission, so plan around that. Credential delegation is enabled unconditionally on lab machines, which is a convenience inside a disposable lab and a decision to revisit the moment a lab is not disposable. And the repository's default branch is the development one while the feature links point at the release branch, so check which copy of a sample you are reading.

Frequently asked questions

Official sources

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