AutomatedLab has moved to GitHub https://github.com/AutomatedLab/AutomatedLab on September 26 2016. There will be no further changes here.
AutomatedLab enables you to setup test and lab environments with multiple products or just a single VM in a very short time. There are only two requirements you need to make sure: You need the DVD ISO images (with product keys) and a Hyper-V host machine.
This solution supports setting up virtual machines with the following products
Windows 7, 2008 R2, 8 / 8.1 and 2012 / 2012 R2, 10 / 2016 TP4
SQL Server 2008, 2008R2, 2012, 2014
Visual Studio 2012, 2013, 2015
System Center Orchestrator 2012
Office 2013, 2016
Some interesting features
Create, restore and remove snapshots of some or all lab machines with one cmdlet (Checkpoint-LabVM, Restore-LabVMSnapshot, Remove-LabVM).
Install Windows Features on one, some or all lab machines with one line of code (Install-LabWindowsFeature).
Install software to a bunch of lab machines with just one cmdlet (Install-LabSoftwarePackages). You only need to know the argument to make the MSI or EXE go into silent installation mode. This can also work in parallel thanks to PowerShell workflows.
Run any custom activity (Script or ScriptBlock) on a number of lab machines (Invoke-LabPostInstallActivity)
You find a step by step instruction on these blog articles:
The AutomatedLab.msi has three components: Modules, Documentation and Sample Scripts. The modules are installed in your private module directory: C:\Users\<username> \Documents\WindowsPowerShell\Modules by default and the documentation and samples
scripts in your personal documents folder. You can change all the locations if you want to.
The sample scripts will give you a quick start. There is a script for setting up just a single Windows 8.1 machine, a small single domain with just one DC and one server up to the full blown scenario with 12 machines and all products listed in the summary
above. You have just to set the paths inside the scripts and put in your product keys. Before the lab gets installed all paths will be checked and you get an error message with further information if there is something wrong.
Just pick one of the sample scripts and set the paths according to your system. Make sure that the ISO images are available. Then just invoke the script in an elevated PowerShell. The installation takes 5 minutes up to several hours depending on the script
you choose and the speed of your drives.
If you want to see some details about the installation process, turn on PowerShell verbose logging using $VerbosePreference = ‘continue’ (always recommended for this solution).
The sample scripts are based on a collection in the Post Installation Activities. The installation puts these custom scripts into the lab source folder.
This solution consists of 6 PowerShell modules that are automating the creation VHD Base Images, Hyper-V VMs with differential disks, configuring the unattended XML file, installing software and doing some final customization.
The lab configuration is saved in XML.
This module provides cmdlets for setting up the lab configuration like virtual network switches, Active Directory domains, ISO images and machines with roles. After setting up your lab you can export it to XML for installation or as a template for later
A standard unattended Xml is used for setting up the machines. Certain values like domain, IP settings, product key and other settings can be changed. The changed unattended Xml file is then copied to the machine.
This module is the key module and the front end to start the lab creation process. It lets you create the machines defined previously and also install all the defined roles. After the roles are installed further customization can be done (PostInstallationActivities,
some demos are included and explained later).
The backend module that does the actual work. It does not depend on the Xml files and should not be used directly.
Redirects verbose and debug messages to log files and is also available here:
Provides a way to copy files and folders to other machines using WinRM
Network and PowerShell Remoting
One of the first things to do is creating a virtual network switch so the host can connect to the virtual machines. For that reason the network switch is of type internal and set to the specified IP address.
To create the virtual network switch use the cmdlet Install-Lab with the switch ‘NetworkSwitches’.
Windows Remoting does not allow to connect to an untrusted computer. In this case all the lab machines are untrusted and we need to relax the security (TrustedHots = *). This is done by the cmdlet Set-LabHostRemoting. After the lab setup is finished you
can set TrustedHosts back to an empty value.
Some installations require a second authentication hop, like the Exchange 2013 installation. This means that the installation user’s credentials need to be forwarded to another machine. By default PowerShell remoting does not give the remote computer
the password so there is nothing to forward. If CredSsp is used the actual credentials are given to the remote computer and the remote computer can use them to create another remote connection to any other box. Your host system needs to allow credentials to
be forwarded. The function Set-LabHostRemoting checks if the policy is configured correctly and prints an error message if not.
Hyper-V Virtual Machines and VHDs
Creating the machines is done by the cmdlet Install-Lab and the switches ‘BaseImages’ and ‘VMs’
The virtual machines are created using the cmdlets provided with Hyper-V. Before creating the VMs reference VHDs are created per OS (New-LabBaseImages) and the operating system image is applied to the reference disk (DISM). BCDBoot.exe is used to make the
disk bootable. When creating a new VM it is always based on one of the reference disks.
For each machine a Unattended.xml file is created with the settings you provided (Computer name, IP address, domain name, etc.) and copied to the VHD. When the machine is started the settings made in that file are applied to the machine.
The installation of roles is done using the Install-Lab cmdlet. It provides a switch for each role.
The role installation is done by PowerShell scripts provided in these modules. They are invoked on the VM using PowerShell Remoting. Hence it is very important that the machines are reachable. The virtual switch created for each lab needs to have an IP address
in the same subnet as the VMs. Some basic validation checks are done prior to the lab installation.
Name resolution is also an issue. The solution works with the IP address as long as the machines have static ones. If not the process relies on finding the machine by name. If the installation complains that a machine cannot be reached (have $VerbosePreference
set to ‘Continue’ to see this), make sure that name resolution works.
Each machine can be assigned a number of PostInstallationActivities. These are invoked after everything else has been done.
A PostInstallationActivity consists of two things:
A script to run
A file dependency, either an ISO image or a folder
If you have chosen ISO image dependency the script to invoke has to be on the hos machine and given by the full path. The cmdlet Invoke-LabPostInstallActivity invokes the script using the cmdlet Invoke-Command which copies it over to the remote machine.
Before that the ISO image is mounted to the VM.
If you go for a folder dependency, the script to execute needs to be part of the folder. The folder gets copied to the VMs root drive and the script is invoked there. By using the switch ‘KeepFolder;
This can be either an ISO image that gets mounted before invoking the script or a folder. If you have specified a folder, it will be copied to the VM. In this case the script is not expected to be on the local machine but inside the folder copied to the
AutomatedLab provides an easy solution to install software to some or all lab machines. The software that you want to install must provide a silent way.
On a single machine
One way is using the cmdlet Install-LabSoftwarePackage that required three parameters
- Path: Takes the local path of the exe or msi
- CommandLine: The command line arguments to tell the exe or msi that you want to install it silently and other parameters that you find necessary
- ComputerName: The machine of the computer to install the software
On multiple machines
If you want to install something on some or even all lab machines you can use the function (actually a workflow) Install-LabSoftwarePackages. This function installs the software asynchronously on all given machines.
Install-LabSoftwarePackages takes a list of LabSoftwarePackages. You can create a software package using the cmdlet Get-LabSoftwarePackage (requires the local path of and the arguments to install the application silenty). A sample how that works can be found
in the BigLab sample script.
- The setup process is based on PowerShell Remoting. The host needs to be able to connect to the virtual machines. If the virtual machine does not have a fixed IPv4 address the normal name resolution process has to resolve the name to the right machine. If
there is another machine with the same name in your organization the setup does not work as DNS overrules other name resolution processes. Machines with static IP addresses are contacted by IP address and not by name.
- If a machine has a not a static IP address and you do not have a DHCP server set up, the machine gets an APIPA address (169.254.x.x). In this case the connection is done using IPv6 if not disabled on your host.
- All credentials are saved in plain text. As this solution is not meant for setting up production environments this should not be a big issue.