Lab environments are powerful tools for learning, proof-of-concept work, and software testing, to name a few. However, building out a lab from scratch, installing operating systems, and adding various roles and resources can be time-consuming and even challenging. AutomatedLab allows for building a lab with very little manual intervention.

Brandon Lee

AutomatedLab is a self-contained solution that provides the tools needed to provision a lab environment in an automated way. AutomatedLab allows:

  • Setting up a lab and test environments
  • Using Hyper-V or Azure with multiple solutions (VMware isn't listed in the documentation, but you can use nested virtualization with a Hyper-V server running on vSphere)
  • Provisioning a single VM very quickly

The main advantages of AutomatedLab are its simplicity and easy commands. For example, creating a single machine consists of three lines:

New-LabDefinition -Name Win10 -DefaultVirtualizationEngine HyperV
Add-LabMachineDefinition -Name Client1 -Memory 1GB -OperatingSystem 'Windows 10 Pro'
Install-Lab

Installing AutomatedLab ^

The installation of AutomatedLab is straightforward. You can pull the modules from the PowerShell gallery or install the solution using a downloaded MSI file. Below, I will show how PowerShell works. The commands documented by AutomatedLab are as follows:

It's not well documented, but I received an error installing AutomatedLabs without it. This installs Pester 5.x vs. the 3.x installed by default:
Install-Module Pester -Force

Install-PackageProvider Nuget -Force
PowerShell Core:
Get-PackageProvider | where name -eq 'nuget' | Install-PackageProvider

Install-Module AutomatedLab -AllowClobber
Installing the AutomatedLab PowerShell module

Installing the AutomatedLab PowerShell module

Creating the Lab Sources folder ^

Now that we have the AutomatedLab PowerShell module installed, we can create the Lab Sources folder as the working directory of AutomatedLab. This is where resources such as ISOs, VHDs, scripts, and other items are stored.

The cmdlet to create the Lab Sources folder is as follows:

New-LabSourcesFolder

It defaults to the root of your CDRIVE. However, this can be modified using the "-Drive" parameter.

Creating a new LabSources folder for AutomatedLab

Creating a new LabSources folder for AutomatedLab

The AutomatedLab cmdlet goes to GitHub and pulls down the .zip file containing the framework of the LabSources folder and extracts it to the defined location. Below is a screenshot of the LabSources folder after the cmdlet finishes.

Viewing the contents of the LabSources folder

Viewing the contents of the LabSources folder

Next, as part of creating the LabSources folder, we need to copy an ISO file into the LabSources > ISOs directory. Below, I have copied a Windows Server 2019 ISO. The ISO file is used when creating your Lab Machine definition file, which we will do below.

Copying a Windows ISO to the ISOs folder for use with AutomatedLab

Copying a Windows ISO to the ISOs folder for use with AutomatedLab

Another resource provided out of the box is the SampleScripts folder, which has scripts for deploying into different types of environments.

AutomatedLab comes with sample scripts for different environments

AutomatedLab comes with sample scripts for different environments

Create a new lab definition ^

The lab definition defines the specifications of the lab to be provisioned by AutomatedLab. The syntax for creating the new lab definition is as follows:

New-LabDefinition -Name <your lab definition name> -DefaultVirtualizationEngine <engine>

In the example below, I use Hyper-V as the default virtualization engine.

Create a new AutomatedLab lab definition

Create a new AutomatedLab lab definition

At this point, you can also list the available operating systems in your Lab Sources folder. To do that, use the following cmdlet:

Get-LabAvailableOperatingSystem

As you can see below, it correctly reads the ISO file in the LabSources > ISO directory and lists out the available Windows Server 2019 editions.

List available operating systems for use with AutomatedLab

List available operating systems for use with AutomatedLab

Create a lab machine definition ^

The lab machine definition defines the machine name and the operating system that will be installed for the virtual machine. This is set using the following cmdlet:

Add-LabMachineDefinition -Name <virtual machine name> -OperatingSystem <Your operating system>

One of the nice features of the AutomatedLab configuration is that the module automatically takes care of the networking side. As you can see below, it creates a new Hyper-V virtual switch and assigns an address space to the environment. The resulting virtual machine(s) will be connected to the new network when the lab is installed.

Add a lab machine definition for AutomatedLab

Add a lab machine definition for AutomatedLab

Installing the lab environment ^

Since we have created the lab definition and the lab machine definition, we are ready to deploy a Windows Server in a VM with AutomatedLab. In this simple demo, the lab installation will create a single instance of Windows Server 2019. To install the lab, run the following cmdlet:

Install-Lab

The Install-Lab cmdlet will ask several security-related questions regarding configuration settings. The configuration settings are required to allow your lab host to interact easily with the resulting lab VMs in the environment. While these are settings you most likely will not want to enable in production, they are mostly OK for a lab environment. They include:

  • Are you OK with enabling WinRM and CredSSP?
  • Are you OK with putting '*' into the TrustedHosts to allow the host to connect to any possible lab VM?
  • Are you fine with setting the AllEncryptionOracle to 2?
Running the Install lab cmdlet for AutomatedLab

Running the Install lab cmdlet for AutomatedLab

If you open an Explorer window and browse to the AutomatedLab-VMs folder, you will see the base image VHD image. Its purpose is to have much quicker subsequent deployments. Therefore, after the base image is created, it simply uses it for future deployments, which take only a minute or two instead of the entire time it takes for the base image.

Base image for Windows Server 2019 is created

Base image for Windows Server 2019 is created

After creating the base image, AutomatedLab creates the actual lab VMs. It waits for these to start, checks WinRM connectivity to verify, and completes afterwards.

Machines are created and AutomatedLab waits for these to start up

Machines are created and AutomatedLab waits for these to start up

After the build completes, if you want to see a summary of the build process for the lab, you can run the following cmdlet:

Show-LabDeploymentSummary

It shows how long it took to build the lab, the lab name, and other summary information. You can open up your Hyper-V Manager and connect to the virtual machine. You can also have AutomatedLab connect via RDP using the following cmdlet:

Connect-LabVM -Computername <your lab computername>
View the resulting AutomatedLab Windows Server 2019 machine

View the resulting AutomatedLab Windows Server 2019 machine

Wrapping up and impressions ^

Deploying a Windows Server in a VM with AutomatedLab is extremely easy. The solution takes the heavy lifting from automating the provisioning of a lab environment that may include Windows Servers, clients, and other solutions such as SQL, Exchange, Active Directory, and others.

Subscribe to 4sysops newsletter!

Combined with the example scripts and scripts from the community built for AutomatedLab, it is a solid, well-documented, and supported tool for automated lab deployments.

avataravatar
0 Comments

Leave a reply

Please enclose code in pre tags

Your email address will not be published. Required fields are marked *

*

© 4sysops 2006 - 2021

CONTACT US

Please ask IT administration questions in the forums. Any other messages are welcome.

Sending

Log in with your credentials

or    

Forgot your details?

Create Account