Last Updated on March 14, 2024 by Michael Morten Sonne

So you’d like to build an Active Directory (AD)/Windows Server lab, and have no idea how to get started right?. I learnt how to build labs manually however, this was quite time consuming and didn’t allow much flexibility – now I had played around with AutomatedLab from GitHub!

To setup an AD lab today we’ll be leveraging AutomatedLab. AutomatedLab is a provisioning solution that lets you deploy simple and complex labs on HyperV and Azure with simple PowerShell scripts – you can make customization to for Active Directory, Office, TFS and Azure!

What is AutomatedLab?

AutomatedLab is simply PowerShell module. In some ways it’s a framework because it encourages a particular workflow for managing named labs consisting of VMs with prefined applications / “roles” or custom roles.

The benefit using AutomatedLab is the simplicity it offers to quickly fire up and throw away environments, and rebuild again if you etc. mess it up (it can happen for us all 😉).
It also offers a huge range of functions to build out whatever you want.

Generally, the workflow goes something like:

• New-LabDefinition
• Add-LabMachineDefinition
• Install-Lab

Those commands have a bunch of different parameters to further configure your lab. But generally, you 1) define your lab, 2) define the VMs and 3) initiate the build.

Technical Requirements:

• Windows Server 2012 R2+/Windows 8.1+
• Operating Systems ISO files for all roles to be deployed
• Administrator Privilege
• Intel VT-x or AMD/V capable CPU
• A generous amount of RAM (24GB+, or a LOT more 😉)
• Hyper-V
• Low-Latency high-throughput storage (No spinning disks, please, as there are issues related to them)

The full list of requirements can be found on their website incl. Supported products.

For now when this post is written, the list is:

• Windows 7, 2008 R2, 8 / 8.1 and 2012 / 2012 R2, 10 / 2016, 2019, 2022
• SQL Server 2008, 2008R2, 2012, 2014, 2016, 2017, 2019 more
• Visual Studio 2012, 2013, 2015, 2017 more
• Team Foundation Services 2015+
• Azure DevOps more
• Exchange 2013, 2016, 2019
• SharePoint 2013, 2016, 2019
• System Center Orchestrator 2012
• System Center Configuration Manager 1809 or 1902+
• System Center Operations Manager
• System Center Virtual Machine Manager
• Microsoft Deployment Toolkit (MDT) more
• ProGet (Private PowerShell Gallery)
• Office 2013, 2016
• DSC Pull Server (with SQL Reporting) more
• Hyper-V more
• Failover Clustering more
• Dynamics 365 more

Skill Requirements:

• Basic understanding of PowerShell
• Basic understanding of Windows Environments and troubleshooting if needed 😉
• Basic understanding of Hyper-V and how to use it

Preperation

Security warning (remember to isolate this as a lab!)

Before you get started, you should know about some changes AutomatedLab wants to make to your computer when you first call an AutomatedLab script.

You’re prompted yes/no to a series of questions which will likely dictate whether you want to use this in a production network or not.

Below I’ll lay out what those changes are and the commands/options it sets.

Enabling WinRM CredSSP

Enable-WSManCredSSP -Role Client -DelegateComputer * -Force

The documentation on this gives the following reason for this change:

Enters a wildcard in your system’s TrustedHosts file

Set-Item -Path Microsoft.WSMan.Management\WSMan::localhost\Client\TrustedHosts -Value '*' -Force

The exception message thrown if you choose not to accept reads:

“AutomatedLab requires the host to connect to any possible lab machine using NTLM... “

If a remote system is not part of a domain, or is part of an untrusted domain, an attempt to connect using remoting may fail. The remote system must either be listed in trusted hosts or must use SSL.

Putting a wild card in your TrustedHosts file will effectively mean your computer trusts all and any remote systems to make connections to, not from. In other words, this wildcard is not the config for allowing all and any remote systems to connect to your computer.

Allow credential delegation via local group policy settings

The following settings are configured with a link to their description:

• Allow Delegating Fresh Credentials
  https://gpsearch.azurewebsites.net/#116
• Allow Delegating Fresh Credentials when NTLM only
  https://gpsearch.azurewebsites.net/#117
• Allow Delegating Saved Credentials
  https://gpsearch.azurewebsites.net/#118
• Allow Delegating Saved Credentials when NTLM only
  https://gpsearch.azurewebsites.net/#119

These settings are relevant to allowing use of CredSSP; letting you feed “fresh” and “saved” credentials to remote systems in your lab.

Relaxes a setting for CredSSP patch CVE-2019-0886

The setting it changes for CVE-2018-0886 / KB4093492 is AllowEncryptionOracle =2:

New-Item -Path HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters -Force | Out-Null Set-ItemProperty -Path HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters -Name AllowEncryptionOracle -Value 2 -Force`

This workaround enables you to connect to lab machines that may not have the CredSSP patch installed.

With all of the the above in mind I encourage you to make an informed decision as to whether you can use AutomatedLab or not.

These are the resources I used to help me understand what I needed to know the risks were, explaining things like Kerberos authentication, CredSSP and double-hopping with PowerShell:

• PowerShell Remoting Kerberos Double Hop Solved Securely
• Understanding Kerberos Double Hop
• Kerberos for the Busy Admin
• Accidental Sabotage: Beware of CredSSP

Download ISOs

AutomatedLab requires you to have some ISOs it can use. It initially creates a base image.

1. Navigate to Windows Evaluation Centre – if you have some .ISO downloaded elseware etc. from your Visual Studio Subscription, you can use them if there are supported products
2. Download a Windows Server and a Windows 11 image (For the purpose of this article we’ll assume Windows Server 2022 and Windows 11 Pro)

Install AutomatedLab

Ok we’re finally ready to install AutomatedLab.

Decided to use it still? Great! I personally use it in my home lab and it works well!

I’m not going to reinvent the wheel. The Installation docs are good enough!

Open an escalated PowerShell Window and execute the following commands:

Install-Module -Name AutomatedLab -AllowClobber
New-LabSourcesFolder -Drive D -Force

Great, now AutomatedLab is installed and ready to use! 🥳

Folders

Once installed, you’ll see a D:\LabSources folder. During installation you can configure where to store LabSources if you don’t want to save it on C.

LabSources is not the directory where your lab VMs are stored. It’s where installation media/sources and scripts are kept. By default, VMs are stored in in a directory named AutomatedLab-VMs but this is also configurable on a per lab basis using -VmPath parameter.

If you don’t explicitly define -VmPath then the fastest available drive on your computer will be used for the AutomatedLab-VMs folder.

AutomatedLab LabSources folder contents

Within each folder for LabSources you’ll have some description detailed within a README.md but I’ll offer some more insight.

LabSources\CustomRoles

AutomatedLab has a concept of “roles” that are installed after a VM OS is installed. Here is a list of predefined / “built in” roles. Associating a role with a VM will install applications such as Exchange, Active Directory, SharePoint, SQL, lots of good stuff and more. You associate a role with a VM using the -Roles parameter with the Add-LabMachineDefinition command.

Custom roles is the ability to create your own role. Your custom role’s name is the name of the directory you save in LabSources\CustomRoles and AutomatedLab calls LabSources\CustomRoles\MyCustomRole\HostStart.ps1 once the VM’s OS is installed. From there, your imagination is the limit.

LabSources\ISOs

VMs need ISO media for operating system installs and some applications sources for roles such as SQL. This is where you must store ISOs. This directory is scanned at runtime when initiating a build and an error will be thrown if what’s required isn’t present.

LabSources\OSUpdates

See the README.md for more information, but essentially, it’s a folder to store updates for you to then trigger regeneration of a new ISO for your lab’s operating systems.

LabSources\PostInstallationActivities

A folder that you shouldn’t need to touch. It’s used internally by AutomatedLab to achieve some customisations for some predefined / “builtin” roles.

LabSources\SampleScripts

A nice folder containing lots of examples where you can glean insight on how to build your own AutomatedLab scripts.

LabSources\SoftwarePackages

Software to-be-installed on VMs in your lab download to this folder and copied to the VMs. In your scripts, if you need to do any similar type of functions of downloading and installing, use this directory.

LabSources\Tools

This folder can be copied to all VMs in a lab so if there’s files/folders you want in common, populate this folder with what you want and use the -ToolsPath parameter with the Add-LabMachineDefinition command.

Place the ISO Images you need

Navigate to etc. D:\Labsources\ISOs and place your ISO files in that folder.

Next open an elevated PowerShell Window and type in the following command (Ensure the filepath points to the right location for the LabSources folder):

Get-LabAvailableOperatingSystem -Path D:\LabSources

This should return a list of all operating system images found in the ISOs folder.

Install your first AD/Windows Server lab

• Open an elevated PowerShell ISE window and copy paste the following lines:

#set labname
$labName = 'SmallClient'

#create an empty lab template and define where the lab XML files and the VMs will be stored
New-LabDefinition -Name GettingStarted -DefaultVirtualizationEngine HyperV -VmPath D:\VMs\Lab

#make the network definition
Add-LabVirtualNetworkDefinition -Name $labName -AddressSpace 192.168.10.0/24

#and the domain definition with the domain admin account
Set-LabInstallationCredential -Username Install -Password Somepass1

#the first machine is the root domain controller. Everything in $labSources\Tools get copied to the machine's Windows folder
Add-LabMachineDefinition -Name DC01 -Network $labName -Memory 2GB -OperatingSystem 'Windows Server 2022 Datacenter (Desktop Experience)' -Roles RootDC -DomainName lab.sonnes.cloud -ToolsPath $labSources\Tools

#the second just a member client. Everything in $labSources\Tools get copied to the machine's Windows folder
Add-LabMachineDefinition -Name Client01 -Network $labName -Memory 2GB -OperatingSystem 'Windows 11 Pro' -DomainName lab.sonnes.cloud -ToolsPath $labSources\Tools

Install-Lab

Show-LabDeploymentSummary -Detailed

There is more information, exampels etc. on my GitHub repo – check it out! 👍

When this PowerShell script is running, the output will look like this when its deloying:

Once you execute the script AutomatedLab will do the following:

1. Download Sysinternals tools and place them into the LabSources folder.
2. It will look for an ISO file that contains the specificed OS name. If it can’t find the ISO it will stop at this point.
3. Will create a virtual switch for the lab
4. Then it will create base images for each operating system
5. It will create a Windows Server 2022 root domain controller with the domain name lab.sonnes.cloud
6. It will also create a Windows 11 Pro client machine connected to the lab.sonnes.cloud domain

Grab a coffee and wait for it to work hard!

• Once completed open an elevated Hyper-V Manager window and ensure everything is running.
• Create a checkpoint for each VM before continuing.
• You’ve succesfully deployed your first AD lab!

Now you can connect the the VM´s in your Hyper-V Manager and enable RDP access to it needed (sometimes easyer to connect and copy files to and from VM´s!)

Adding or removing lab machines

While you can delete the Hyper-V virtual machines from the VMM service and vhdx/vmcx files off disk, AutomatedLab will still think they exist. AutomatedLab keeps track of what’s where within the realm of AutomatedLab via XML files which can be found in C:\ProgramData\AutomatedLab\Labs.

To delete individual VMs, use Remove-LabVM. To remove all VMs associated with a lab, use Remove-Lab.

Using these functions is important because not only does it take care of tidying up for you, it also does extra things like removes lab VMs from your hosts file.

As for adding machines to an existing lab, at the time of writing this, there’s no function available within AutomatedLab to specifically add a new VM to an existing lab. It’s only achievable by modifying or creating a new AutomatedLab script with the same properties (e.g. domain, address space etc) and calling Install-Lab -NoValidation.

Removing the hole Lab

Open an elevated PowerShell window and execute the following commands:

Get-Lab -List
Import-Lab LabName
Remove-Lab