Summary

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.

Supported products

This solution supports setting up Windows 8 / 8.1 and Windows Server 2012 / 2012 R2 machines with the following products

-          Windows 7, 2008 R2, 8 / 8.1 and 2012 / 2012 R2, 10 (Technical Preview)

-          SQL Server 2012

-          Visual Studio 2012 / 2013

-          Exchange 2013

-          System Center Orchestrator 2012

-          Office 2013

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)

Quick start

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.

 

Sample Scripts

All given installation times are measured on a SSD RAID 0.

SmallLab1 2012R2.ps1 (about 10 minutes)

This lab provides:

-          One domain controller in one domain

For this lab for example you need just one ISO image:

-          en_windows_server_2012_r2_x64_dvd_2707946.iso

 

SmallLab1 2012R2 SQL.ps1 (about 40 minutes)

This lab provides:

-          One domain controller in one domain

-          A SQL 2012 server

For this lab for example you need just one ISO image:

-          en_windows_server_2012_r2_x64_dvd_2707946.iso

-          en_sql_server_2012_standard_edition_with_sp1_x64_dvd_1228198.iso

SmallLab1 2012R2 EX.ps1 (about 90 minutes)

This lab provides:

-          One domain controller in one domain. About 7.000 users are added to the domain

-          An Exchange 2013 organization with one server

For this lab for example you need just one ISO image:

-          en_windows_server_2012_r2_x64_dvd_2707946.iso

-          mu_exchange_server_2013_x64_dvd_1112105.iso

The domain controller has defined two PostInstallationActivities. A LabPostInstallationActivity can run a script or executable to customize the machine after installation. The used PostInstallationActivities are available for download and should be in a separate folder named “PostInstallationActivities” under the lab sources. The first script PrepareRootDomain.ps1 creates just a couple of users for working with the environment. New-ADLabAccounts 1.0.ps1 creates about 7.000 accounts in a quite complex hierarchy for a pure lab.

Single Win81 Client.ps1 (about 10 minutes)

This lab provides:

-          A single non-domain joined Windows 8.1 client

For this lab for example you need just one ISO image:

-          en_windows_8_1_x64_dvd_2707217.iso

Single Win81 Client VS OFF.ps1 (about 20 minutes)

This lab provides:

-          A single non-domain joined Windows 8.1 client with Visual Studio 2013 and Office 2013 (no key provided and not activated)

For this lab for example you need just one ISO image:

-          en_windows_8_1_x64_dvd_2707217.iso

-          en_visual_studio_ultimate_2013_x86_dvd_3009107.iso

-          en_office_professional_plus_2013_x86_dvd_1123673.iso

 

MediumLab1 2012R2 SQL EX.ps1 (about 150 minutes)

This lab provides:

-          Two domain controller in two domains. 7.000 users are added to the child domain

-          An Exchange 2013 organization with one server in the child domain

-          A SQL 2012 server in the child domain with sample databases added after installation

-          A Windows 8.1 client with Visual Studio 2013 and .net 3.5 installed.

For this lab for example you need just one ISO image:

-          en_windows_server_2012_r2_x64_dvd_2707946.iso

-          en_windows_8_1_x64_dvd_2707217.iso

-          mu_exchange_server_2013_x64_dvd_1112105.iso

-          en_sql_server_2012_standard_edition_with_sp1_x64_dvd_1228198.iso

-          en_visual_studio_ultimate_2013_x86_dvd_3009107.iso

There are three PostInstallationActivities defined here:

-          The root domain get prepared by PrepareRootDomain.ps1

-          Users are created in the child domain by New-ADLabAccounts 1.0.ps1

-          Sample databases are installed and added to the SQL server by InstallSampleDBs.ps1

-          .net Framework 3.5 is installed onto the client by DotNet35Client.ps1

 

BigLab 2012R2 EX SQL ORCH VS OFF.ps1 (about 230 – 300 minutes)

This lab provides:

-          6 domain controller in 3 domains. 7.000 users are added to the first child domain

-          An Exchange 2013 organization with one server in the first child domain

-          A SQL 2012 server in the first child domain with sample databases added after installation

-          Orchestrator 2012 is installed in the first child domain

-          A simple file server in the first child domain

-          2 Windows 8.1 clients with Office 2013. One client also gets Visual Studio 2013 and .net Framework 3.5

For this lab for example you need just one ISO image:

-          en_windows_server_2012_r2_x64_dvd_2707946.iso

-          en_windows_8_1_x64_dvd_2707217.iso

-          mu_exchange_server_2013_x64_dvd_1112105.iso

-          en_sql_server_2012_standard_edition_with_sp1_x64_dvd_1228198.iso

-          en_visual_studio_ultimate_2013_x86_dvd_3009107.iso

There are three PostInstallationActivities defined here:

-          The root domain get prepared by PrepareRootDomain.ps1

-          Users are created in the child domain by New-ADLabAccounts 1.0.ps1

-          Sample databases are installed and added to the SQL server by InstallSampleDBs.ps1

-          .net Framework 3.5 is installed onto the client by DotNet35Client.ps1

After the machines are set up, some additional software packages are installed. These need to be in folder “SoftwarePackages” also under the lab sources folder. If you download the current version please update the filename in the script accordingly. The command line parameters to install the software silently will pretty likely no change.

The scripts install the following software to all machines:

-          Classic Shell

-          Notepad++

-          WinRAR

 

Technical Summary

PowerShell Modules

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.

  •          AutomatedLabDefinition

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 use.

  •          AutomatedLabUnattended

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.

  •          AutomatedLab

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).

  •          AutomatedLabWorker

The backend module that does the actual work. It does not depend on the Xml files and should not be used directly.

  •          PSLog

Redirects verbose and debug messages to log files and is also available here: http://gallery.technet.microsoft.com/scriptcenter/PSLog-Send-messages-to-a-db389927

  •          PSFileTransfer

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.

 

Role installation

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.

PostInstallationActivity

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 VM.

 

Software Installation

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.

 

Creating the lab definition

The module AutomatedLabDefinition is designed for that. It allows you to create the lab definition using cmdlets and export the result to XML. Of course you can create the XML file manually as well if this seems more flexible or comfortable.

The available cmdlets are:

  •          New-LabDefinition

This creates a new empty container for the lab. You have to specify the path to store the XML files and another path for storing the VMs

  •          Add-LabVirtualNetworkDefinition

This adds the virtual network switch to the lab. Required are the parameters Name, IpAddress and PrefixLength.

Note: At the moment there is just one virtual network switch supported in a lab. The prefix parameter is not working and the subnet will be always 255.255.255.0, 24 bits.

  •          Add-LabDomainDefinition

Each domain has to be specified here. If there are machines belonging to a non-specified domain, the installation process will not start. This means that all domains have to be added, the forest root as well as all child domains. You need to specify the AdminUser and the AdminPassword. These credentials are used for installing the domain controllers.

  •          Add-LabIsoImageDefinition

All images used as a source need to be added with this cmdlet. Required is the path to the ISO image and the name that is used internally to refer to the ISO.

 

If the ISO is an OS images the OS image name is required (parameter OsName) as well as the ImageType (Client or Server) and the name of the reference or base image (parameter ReferenceDisk).

The names of the ISOs image are hard-coded for the following roles:

o   SQL Server (SQL Server 2012)

o   Exchange (Exchange 2012)

o   DevTools (Visual Studio 2012)

o   Orchestrator (System Center Orchestrator 2012)

o   ConfigManager (System Center Configuration Manager 2012)

 

  •          Add-LabMachineDefinition

This cmdlet adds machines to the lab definition. Most of the parameters are quite self-explaining:

o   DiskSizeInGb

o   DnsServer1

o   DnsServer2

o   DomainName

The domain has to be specified using the cmdlet Add-LabDomainDefinition first.

o   Gateway

o   InstallationUserCredential

A PSCredential Object like Get-Credential returns it.

o   IpAddress

o   IsDomainJoined

o   MemoryInMb

o   Name

o   Network

The name of the virtual network that already has been added using the cmdlet Add- LabVirtualNetworkDefinition.

o   PassThru

o   PostInstallationActivity

o   Processors

The number of processors

o   ProductKey

o   Roles

The roles are not defined as a string but as a role object. To get a role object use the cmdlet

o   Type

Client or Server

UnattendedXml
The name of the unattended Xml file for this machine.

o   Tools
The folder specified here is copied to the Windows directory of the VM. If you have a set of tools you want to have on all machines just put them in one folder and point to it.

 

  •          Get-LabMachineRoleDefinition

The create a role object that you can pass to the Add-LabMachineDefinition cmdlet’s role parameter

  •          Get-PostInstallationActivity

This creates a custom Activity to be that be passed to the parameter PostInstallationActivity of the cmdlet Add-LabMachineDefinition

 

Work in Progress

Patching

It is planned to provide an offline patching of the base images so all machines will be up to date with the latest security fixes

System Center Configuration Manager 2012

A guide that explains how to use the PowerShell Doployment Toolkit (http://blogs.technet.com/b/privatecloud/archive/2013/02/08/deployment-introducing-powershell-deployment-toolkit.aspx) with the AutomatedLab solution would be nice.

Active Directory Replication Topology

At the moment a PowerShell script has to be used to create a replication topology. It is planned to provide this as part of the lab definition.

 

Known Issues

Virtual Machine Creation

-          For installation VHDs are mounted to the host machine to copy date to the virtual drives. Therefore the explorer pops up and may show access denied errors and “Format Drive” dialogs. Just ignore them, they don’t interrupt the installation process.

Network

-          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.

-          The network subnet mask is ways 24 bits. Defining other subnet masks is going to work in the next release.

-          Windows 8 Clients need quite a long time until they can be contacted after the OS is installed. Please be patient. Windows Server 2012 does not cause this delay.

-          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.

Credential Handling

-          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.

-          So far this solution has not been tested with different installation credentials. All entities – domain controllers, member servers and clients – are sharing the same administrative credentials. This will change in the next releases.

Domain setup

-          There is a timing issue setting up the domain controllers. Sometimes promoting a second domain controller does not work and the machine complains that it cannot contact the domain.

PostInstallationActivities

-          The implementation needs to be more flexible and is going to be redesigned in the next version. There is also some misalignment with the parameter set in the AutomatedLab module and the worker module.

Documentation

-          Unfortunately the cmdlets do lack documentation and this document all there is that describes how AutomatedLab works.

Version History

  • 2.5
    • Added support for Windows 10 Technical Preview (Client and Server)
    • Optimized the session and job usage
    • Timeout counters and configuration data is now centrally configurable in the PSD1 file
  • 2.2
    • Support for Subordinate Certificate Authorities
    • Installing software does no longer use workflows but background jobs, which is much faster
    • Removing a lab does no longer require to import it first if using the Path parameter
    • Adjusted all sample scripts to work with version 2.x
    • New validators to verify virtual switch settings
    • Bug fixing
    • Parallel Domain Controller installation
    • PSSession reuse and cleanup
    • New cmdlet: Stop-LabVM
    • New cmdlet: Enter-LabPSSession
    • PostInstallationActivities can be put in background (AsJob)
    • Many performance improvements
  • 2.1.0
    • Support for external virtual switches
    • CaRoot is a new role for installing Root Certificate Authorities
    • Root domain controllers are installed in parallel now
  • 2.0.0
    • Now supports also Windows Server 2008 R2 and 7
    • No longer the limit of just having one client and one server operating system
    • Rewrite of the code that handles VHDs
    • Lots of bug fixing
    • Changed that parameter definition of some cmdlets in AutomatedLabDefinition and also adapted the sample scripts
  • 1.5.5
    • You can now specify the user locale for a new machine
    • You can now specify the time zone for a new machine
    • One new sample scripts to set up a single Windows 2012 R2 server
    • Added public KMS keys to all sample scripts
    • Fixed issues and done minor changes (see source code history for details)
    • Performance optimization: Altered sleep timers and disabled Windows Defender
  • 1.5.2
    • Small but effective performance updates
    • Introduces Web Server Role
    • Fixed issues with setting Hyper-V hosts CredSsp policies
    • Fixed domain membership of KerbWeb0 to test.net
  • 1.5.1
    • Bug Fixing: Using different credentials in inside a lab scenario didn?t work and does now.
    • Added a multi-forest scenario that connects three forests to the sample scripts
  • 1.5.0
    • Changed the way how name resolution is done. AutomatedLab now updates the hosts file
    • Introduced Remove-Lab to clean the host if a lab is no longer needed
    • Support for domain trees additionally to child domains
  • 1.4.1
    • Fixing bugs in the Exchange Install routine
    • Support for multi forest environment including cross-forest DNS setup and trusts
  • 1.4
    • Rebuild the PostInstallationActivity functions. These are the main building block to do custom things on the lab machines.
    • Introduced a feature to install software (Install-LabSoftwarePackage).
    • Introduced a feature to install software in parallel (workflow Install-LabSoftwarePackages).
    • Introduces cmdlets for managing snapshots for all or some machines in a lab.
    • Provided the setup scripts for Exchange 2013 (single server)
    • Provided the setup script for Office 2013 installation
    • This version also installs Visual Studio 2013
  • 1.0: The initial release August 2013

 

Last edited Wed at 9:18 AM by raandree, version 13