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:
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.
- 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 😉)
- 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
- Basic understanding of PowerShell
- Basic understanding of Windows Environments and troubleshooting if needed 😉
- Basic understanding of Hyper-V and how to use it
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:
“Every machine deployed with AL has CredSsp enabled as a CredSsp server. This is like running “Enable-WSManCredSSP -Role Server”. Invoke-LabCommand always tries to make a connection with CredSsp. If this does not work you will see a warning and a connection without CredSsp is tried. This is definitely not a best practice for a production environment but makes life much easier in a lab. Using CredSsp you can create a remote session from a remote session which is extremely helpful when installing or setting up a lab. For example, reading an AD user account from a remote session does not work without CredSsp as reading data from Active Directory requires and authentication from the remote machine to a domain controller. Inside an AL lab the following code works out of the box.”
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
- Allow Delegating Fresh Credentials when NTLM only
- Allow Delegating Saved Credentials
- Allow Delegating Saved Credentials when NTLM only
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
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
AutomatedLab requires you to have some ISOs it can use. It initially creates a base image.
- 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
- 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)
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! 🥳
Note: There is a MSI installer also
Note: When you run AutomatedLab for the first time you will see some prompts related to PowerShell remoting.
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.
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.
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
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.
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.
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.
A folder that you shouldn’t need to touch. It’s used internally by AutomatedLab to achieve some customisations for some predefined / “builtin” roles.
A nice folder containing lots of examples where you can glean insight on how to build your own AutomatedLab scripts.
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.
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
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:
- Download Sysinternals tools and place them into the LabSources folder.
- 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.
- Will create a virtual switch for the lab
- Then it will create base images for each operating system
- It will create a Windows Server 2022 root domain controller with the domain name lab.sonnes.cloud
- 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.
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
Removing the hole Lab
Open an elevated PowerShell window and execute the following commands:
Get-Lab -List Import-Lab LabName Remove-Lab