AutomatedLab Tutorial Part 2: Create a Simple Lab

Summary: Learn how to create a small lab environment by using AutomatedLab.

Microsoft Scripting Guy, Ed Wilson, is here. Today we have Part 2 of the series by Microsoft PFEs, Raimund Andree and Per Pedersen. Today they talk about installing the Windows PowerShell modules to use with AutomatedLab, and the steps required to create a simple lab. If you follow along, you will have AutomatedLab installed on your Hyper-V host and a lab set up with two machines.

Note  Before you read this post, you might benefit from reading AutomatedLab Tutorial Part 1: Introduction to AutomatedLab.

Installation

The installation of AutomatedLab is very easy. You can find the information you need on Microsoft TechNet: AutomateLab. The download consists of one .msi file.

After starting the installer (the .msi file), you will see three options: Typical, Custom, or Complete. If you have more than one logical disk (or even better, more than one physical disk), you can take advantage of it and choose the Custom setup.

In time, the Lab Sources folder can grow quite large, so you might want to choose a drive other than drive C.

Note  Feel free to change installation folders as you wish. However, to automatically import the Windows PowerShell modules that come with AutomatedLab, the modules must be installed in either the user-specific path (C:\Users\\Documents\WindowsPowerShell\Modules) or the computer-specific path (C:\Windows\System32\WindowsPowerShell\v1.0\Modules).

Assuming that you did not change the default directories, after you perform the installation, you will have seven new Windows PowerShell modules in the user-specific path for Windows PowerShell modules: C:\Users\\Documents\WindowsPowerShell\Modules.

In your documents folder, you will find the sample scripts and the documentation.  The folder names are AutomatedLab Sample Scripts and AutomatedLab Documentation.

An important part is the folder hierarchy of Lab Sources. (The purpose of this folder was explained in AutomatedLab Tutorial Part 1: Introduction to AutomatedLab.)

Installation done.

Prerequisites for installing the first lab

Three requirements need to be verified, before a lab can be created:

1. AutomatedLab requires Hyper-V in Windows Server 2012 R2 or Windows 8.1
2. The ISO files to be used during creation of the lab need to be present in \LabSources\ISOs.
3. Windows PowerShell remoting needs to be enabled on the host machine.

The first thing to do is to acquire ISO files for Windows Server 2012 R2 and Windows 8.1. The ISO files must provide a Standard or Datacenter version of Windows Server 2012 R2 and a Professional or Enterprise version of Windows 8.1.

If you want to know which operating system versions your ISO files contain, use the following command:

Get-LabAvailableOperatingSystems -Path

Enable Windows PowerShell remoting on the host computer (described in the previous post). This is required, and it has to be done only once.

Open an elevated command prompt in Windows PowerShell and type the command Set-LabHostRemoting. The output looks like this:

VERBOSE: starting log

VERBOSE: Set-LabHostRemoting Entering… )

VERBOSE: Remoting is enabled on the host machine

WARNING: TrustedHosts does not include ‘*’. Replacing the currernt value ” with ‘*’

VERBOSE: Local policy ‘Computer Configuration -> Administrative Templates -> System -> Credentials Delegation -> Allow Delegating Fresh Credentials’ configured correctly

VERBOSE: Local policy ‘Computer Configuration -> Administrative Templates -> System -> Credentials Delegation -> Allow Delegating Fresh Credentials’ configured correctly

VERBOSE: Set-LabHostRemoting…leaving.

Note  **Because running the command **Set-LabHostRemoting sets TrustedHosts to ‘*’, your host computer will now allow (any) credentials to be sent from your host computer to any other computer. This is a security risk that you need to be aware of. If you will not allow this, you will need to modify this configuration manually after running the command Set-LabHostRemoting.
To modify trusted hosts:

1. Opening gpedit.msc, go to Computer Configuration > Administrative Templates > System > Credentials Delegation.
2. Modify the following policies: Allow delegating fresh credentials and Allow delegating fresh credentials with NTLM-only server authentication.
3. Change content to only allow credentials to be sent to the computers of your choice. For AutomatedLab to work, you will need to enter names for all virtual machines deployed by using AutomatedLab.

Create the first lab

When the prerequisites are fulfilled, a lab can be created. Creating a lab consists of several tasks, which are described in the following sections of this post.

Basic metadata information

First you need to define the metadata information regarding where to look for data and where to store data. The files that need to be read are the files in the LabSources directory. You need to define information about the lab definition (to make is persist when exiting the Windows PowerShell session and restarting the host computer). Also, information about where to store the virtual machines is needed.

Note  For performance reasons, it is a good idea to place the virtual machines on a separate (physical) drive from the operating system, and preferably this drive should be an SSD. AutomatedLab uses a parent disk for each operating system, and creates differentiating disks for each virtual machine using the parent disks as base disks. By placing the ISO files on a separate drive from the virtual machines (where the reference disks are also stored), creating the reference disks will be faster (although this task only needs to be executed once because the parent disks are never modified after they are created).
Also, for performance reasons, it is highly recommended to exclude the folder of the ISO files and the folder for the virtual machines from being scanned by antivirus software (real-time scanning).

In the following example, Lab Sources (containing the ISO files) is placed on drive E (which is a mechanical drive), and he virtual machines will be created on drive D (which is an SSD):

$labSources = ‘E:\LabSources’ #here are the lab sources

$vmDrive = ‘D:’ #this is the drive where to create the VMs

$labName = ‘FirstLab’ #the name of the lab, virtual machine folder and network switch

#create the folder path for the lab using Join-Path

$labPath = Join-Path -Path $vmDrive -ChildPath $labName

#create the target directory if it does not exist

if (-not (Test-Path $labPath)) { New-Item $labPath -ItemType Directory | Out-Null }

Define the lab

A lab definition is a set of data that contains information about the lab environment, such as the lab name, network adapter, the domains, and the configuration of the machines (for example, name, number of CPUs, amount of memory, machine roles). This definition is created by calling New-LabDefinition.

The following command will create a new lab definition:

New-LabDefinition -Path $labPath -VmPath $labPath -Name $labName -ReferenceDiskSizeInGB 60

Define the network

All virtual machines in the lab need to have a network adapter. This network adapter is connected to a Hyper-V virtual switch. This Hyper-V virtual switch needs to be created for the lab. By default, this Hyper-V virtual switch will be created as an internal switch, providing the host computer network access to the virtual machines and vice versa. However, the virtual machines cannot connect to your physical network or vice versa. Here, for simplicity, the network name will be the same as the lab name:

#define the network

Add-LabVirtualNetworkDefinition -Name $labNetworkName -IpAddress 192.168.81.1 -PrefixLength 24

In this scenario, the lab is going to use IP addresses in the subnet 192.168.81.x, which has the subnet mask 255.255.255.0. Possible IP addresses are 192.168.81.1-192.168.81.255

Note  The IP address 192.168.81.1 will automatically be used as the IP address of the Hyper-V virtual switch that is seen from the host operating system. Therefore, this IP address cannot be used for virtual machines in the lab.

Define domains

If you want to create only standalone machines (machines in a workgroup), no domain is required. However, in this lab, there will be one domain with one domain controller and one member server. As such, a domain needs to be defined for the lab.

This domain definition will include the domain name, the administrator, and the password of the administrator. This account is used for all domain-related tasks such as the domain controller promotion, setting the DSRM/DSREPAIR password, and joining machines to the domain.

#domain definition with the domain administrator account

Add-LabDomainDefinition -Name test1.net -AdminUser administrator -AdminPassword Password1

Add ISOs to the lab

All required ISO files for software (operating systems, server applications, and client applications) to be used in the lab need to be defined for AutomatedLab to find it. If you add an operating system ISO, you need to mark it with the IsOperatingSystem switch. The Name parameter is used only to uniquely identify the ISO definition, and it is not used elsewhere. The name is your choice, but it has to be unique in the lab.

#these images are used to install the machines

Add-LabIsoImageDefinition -Name Server2012R2 -Path $labSources\ISOs\ en_windows_server_2012_r2_with_update_x64_dvd_4065220.iso

–IsOperatingSystem

Choose credentials to be used to connect to machines

For the initial setup of each virtual machine, a user name and password is needed to define the user name and password of the local administrator. This information is stored in a file named unattended.xml. This file is then used to perform the initial set up for each virtual machine.

**Disclaimer  **Creating a PSCredential object by using a plain text password is absolutely not a best practice for any production environment. However, because this lab environment will not be a production environment, a plain text password will be used.****

#these credentials are used for connecting to the machines. As this is a test lab we use clear-text passwords

$installationCredential = New-Object PSCredential(‘Administrator’, (‘Password1’ | ConvertTo-SecureString -AsPlainText -Force))

Define roles

Using roles in AutomatedLab will be the easiest way to customize a machine and set it up as required. In version 2.1.0, AutomatedLab supports the following roles: 

RootDC	Root domain controller for a domain
FirstChildDC	First child domain controller for a domain
DC	Additional domain controller for a domain
DHCP	DHCP server role
FileServer	File Server role
WebServer	Web Server role (all web role services)
SQLServer2012	SQL Server 2012 with default instance
Exchange2013	Exchange Server 2013
Orchestrator	System Center Orchestrator 2012
CaRoot	Enterprise or standalone Root Certificate Authority (Windows Server 2012 or Windows Server 2012 R2)
CaSubordinate	Enterprise or standalone subordinate certification authority (Windows Server 2012 or Windows Server 2012 R2)
Office2013	Microsoft Office 2013
DevTools	Visual Studio 2013 and Visual Studio 2012

In this lab, only a single role will be used: the RootDC role. The lab will contain a domain, so a new Active Directory forest is required—and this, of course, requires a root domain controller. A requirement for defining a root domain controller is to provide the ForestFunctionalLevel and the DomainFunctionalLevel.

This information is specified by using a Properties parameter, which is a hash table. There is no documentation yet for this part, so this is a good opportunity to make mistakes. However, avoiding mistakes in regards to this parameter is not crucial because all the lab definitions will be validated by AutomatedLab before the installation is actually started.

In our case, the validation component makes sure that the ForestFunctionalLevel and DomainFunctionalLevel parameters are defined, and that they are not higher than the version of the operating system of the machine.

The cmdlet Get-LabMachineRoleDefinition has a role parameter and a properties parameter. Although the properties parameter is not mandatory for some roles, it is mandatory for domain controllers. Calling Get-LabMachineRoleDefinition returns a role object. This role object is later used when defining a lab machine.

$role = Get-LabMachineRoleDefinition -Role RootDC -Properties @{ DomainFunctionalLevel = ‘Win2012R2’; ForestFunctionalLevel = ‘Win2012R2’ }

Define a lab machine

The first lab machine is defined by using the cmdlet Add-LabMachineDefinition. Here, the name of machine is provided in addition to basic information such as number of CPUs, memory, and IP configuration.

Furthermore, it can be specified that the machine is to be domain-joined, will be in the domain test1.net, and that the machine should have the root domain controller role (defined in the previous step). This effectively results in defining that we want a root domain controller in the forest test1.net.

Next, you need to provide the installation credentials. These credentials will be required to connect to the machine later for doing administrative tasks.

The ToolsPath parameter is optional, and it points to a folder of your choice on the host. If you use this parameter, AutomatedLab will copy the contents of this folder to all of the virtual machines in the lab, prior to starting them. This is an effective way of copying the tools and utilities of your choice to all of the virtual machines in the lab.

Finally, the operating system needs to be defined. This parameter is restricted to a number of supported operating systems. IntelliSense in Windows PowerShell helps you finding the desired value. Make sure to provide the value in quotation marks (after IntelliSense) because the operating system names contain white spaces.

Add-LabMachineDefinition -Name S1DC1 `

    -MemoryInMb 512 `

    -Network $labNetworkName `

    -IpAddress 192.168.81.10 `

    -DnsServer1 192.168.81.10 `

    -DomainName test1.net `

    -IsDomainJoined `

    -Roles $role `

    -InstallationUserCredential $installationCredential `

    -ToolsPath $labSources\Tools `

    -OperatingSystem ‘Windows Server 2012 R2 SERVERDATACENTER’

The first machine is now defined.

To add a second machine to the lab, merely a copy and paste the previous command. Only the name and the IP address are different. In addition, this virtual machine will not be associated with any role. If no role is defined, the virtual machine will simply be a member of the domain.

Add-LabMachineDefinition -Name S1Server1 `

    -MemoryInMb 512 `

    -Network $labNetworkName `

    -IpAddress 192.168.81.20 `

    -DnsServer1 192.168.81.10 `

    -DomainName test1.net `

    -IsDomainJoined

    -InstallationUserCredential $installationCredential `

    -ToolsPath $labSources\Tools `

    -OperatingSystem ‘Windows Server 2012 R2 SERVERDATACENTER’

Export the lab

After configuring all the lab definitions, you can export the lab configuration by using the Export-LabDefinition cmdlet. This cmdlet creates two XML files in the directory ‘D:\FirstLab’. These files contain the configuration of the lab, which makes them persistent.

Export-LabDefinition -ExportDefaultUnattendedXml –Force

The Force switch overwrites existing files without asking for permission.

Install the first lab

After you have configured all the lab definitions and the configuration has been saved to disk, the lab can be installed. This is done by using the Install-Lab cmdlet. By using different switches, you can activate different tasks to be performed by Install-Lab. The following table lists the switches that are currently available.

Switch	Task
NetworkSwitches	Creates the virtual switch
BaseImages	Creates all parent disks
VMs	Creates and configures all the Hyper-V virtual machines
Domains	Starts installation of all domain controllers starting with root domain controllers, then child domain controller and additional domain controllers
DHCP	Installs DHCP role on machines where this role is specified
CA	Installs the Certificate Authority roles if specified
PostInstallations	Starts on post installation actions
SQLServer2012	Installs SQL server on machines where this role is specified
Orchestrator	Installs SC Orchestrator on machines where this role is specified
WebServers	Installs Web server role on machines where this role is specified
Exchange2013	Installs Exchange Server on machines where this role is specified
DevTools	Installs DevTools (Visual Studio) on machines where this role is specified
Office2013	Installs Office 2013 where this role is specified
StartRemainingMachines	Starts all remaining machines (the machines which has not yet been started)

Call Install-Lab

The current lab contains only a domain controller and a member machine, so the following parameters for Install-Lab are needed:

• NetworkSwitches
  This creates the virtual switch. By default, the virtual switch is an internal switch, so the virtual machines cannot connect to any network resources outside of the lab and the host.
• BaseImages
  AutomatedLab creates one base image for every operating system. All virtual machines use these disks as parent disks.
• VMs
  This creates and configures each virtual machine using differencing disks.
• Domains
  This installs all domain controllers. In one lab, it is possible to create multiple forests, multiple child domains, or domain trees, and use both RODCs and RWDCs. This task installs all specific roles for the domain controller.
• StartRemainingMachines
  All machines defined in the lab that have not been started will be started in this task. This task is important because starting the machines triggers the unattended installation based in the XML files that AutomatedLab created for you. This unattended.xml file contains configuration for each machine, such as computer name, IP address, locale, and domain.

In the following example, Install-Lab is called three times to separate the process. However, you can start all tasks in a single call by using all the required switch parameters.

Install-Lab -NetworkSwitches -BaseImages -VMs

#This sets up all domains / domain controllers

Install-Lab -Domains

#Start all machines which have not yet been started

Install-Lab -StartRemainingMachines

These tasks will take a considerable amount of time, depending on the speed of you disks. When the tasks are complete, the lab is ready to use. Congratulations!

Remove a lab

Removing the small lab described in this post is quite easy. However, if a lab of 10+ machines needs to be removed, the task becomes tedious. AutomatedLab also contains a cmdlet that can help clean up all the machines used in a lab.

The Remove-Lab cmdlet first removes all the virtual machines used in a lab, then the disks, and finally the network adapter. This enables you to sequentially perform lab installations first, then perform tests in the lab, remove the lab, install a new lab, perform tests, and so on.

Of course, checkpoints that enable you to revert are also available. One of the later blog posts in this series will show how you can take advantage of this functionality.

The full script

This is how the full script should look like after putting all the pieces together:

$start = Get-Date

$labSources = ‘E:\LabSources’ #here are the lab sources

$vmDrive = ‘D:’ #this is the drive where to create the virtual machines

$labName = ‘FirstLab’ #the name of the lab, virtual machine folder and network Switch

#create the folder path for the lab using Join-Path

$labPath = Join-Path -Path $vmDrive -ChildPath $labName

#create the target directory if it does not exist

if (-not (Test-Path $labPath)) { New-Item $labPath -ItemType Directory | Out-Null }

New-LabDefinition -Path $labPath -VmPath $labPath -Name $labName -ReferenceDiskSizeInGB 60

Add-LabVirtualNetworkDefinition -Name $labName -IpAddress 192.168.81.1 -PrefixLength 24

Add-LabDomainDefinition -Name test1.net -AdminUser administrator -AdminPassword Password1

Add-LabIsoImageDefinition -Name Server2012R2 -Path $labSources\ISOs\en_windows_server_2012_r2_with_update_x64_dvd_4065220.iso –IsOperatingSystem

$installationCredential = New-Object PSCredential(‘Administrator’, (‘Password1’ | ConvertTo-SecureString -AsPlainText -Force))

$role = Get-LabMachineRoleDefinition -Role RootDC -Properties @{ DomainFunctionalLevel = ‘Win2012R2’; ForestFunctionalLevel = ‘Win2012R2’ }

Add-LabMachineDefinition -Name S1DC1 `

-MemoryInMb 512 `

-Network $labName `

-IpAddress 192.168.81.10 `

-DnsServer1 192.168.81.10 `

-DomainName test1.net `

-IsDomainJoined `

-Roles $role `

-InstallationUserCredential $installationCredential `

-ToolsPath $labSources\Tools `

-OperatingSystem ‘Windows Server 2012 R2 SERVERDATACENTER’

Add-LabMachineDefinition -Name S1Server1 `

-MemoryInMb 512 `

-Network $labName `

-IpAddress 192.168.81.20 `

-DnsServer1 192.168.81.10 `

-DomainName test1.net `

-IsDomainJoined `

-InstallationUserCredential $installationCredential `

-ToolsPath $labSources\Tools `

-OperatingSystem ‘Windows Server 2012 R2 SERVERDATACENTER’

Export-LabDefinition –Force -ExportDefaultUnattendedXml

Import-Lab -Path (Get-LabDefinition).LabFilePath

Install-Lab -NetworkSwitches -BaseImages -VMs

#This sets up all domains / domain Controllers

Install-Lab -Domains

#Start all machines which have not yet been started

Install-Lab -StartRemainingMachines

$end = Get-Date

Write-Host “Setting up the lab took $($end – $start)”

What’s next?

The next post describes how checkpoints work in AutomatedLab and how to define your own post-installation activities to help you customize your lab even further.

~Raimund and Per

Way cool! Join us tomorrow for more goodies by Raimund and Per.

I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.

Ed Wilson, Microsoft Scripting Guy