{"id":474,"date":"2014-10-27T00:01:00","date_gmt":"2014-10-27T00:01:00","guid":{"rendered":"https:\/\/blogs.technet.microsoft.com\/heyscriptingguy\/2014\/10\/27\/automatedlab-tutorial-part-2-create-a-simple-lab\/"},"modified":"2022-06-22T08:55:01","modified_gmt":"2022-06-22T15:55:01","slug":"automatedlab-tutorial-part-2-create-a-simple-lab","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/scripting\/automatedlab-tutorial-part-2-create-a-simple-lab\/","title":{"rendered":"AutomatedLab Tutorial Part 2: Create a Simple Lab"},"content":{"rendered":"

Summary<\/b>: Learn how to create a small lab environment by using AutomatedLab.<\/span><\/p>\n

\n 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.\n<\/p>\n

\n Note<\/b>\u00a0\u00a0Before you read this post, you might benefit from reading AutomatedLab Tutorial Part 1: Introduction to AutomatedLab<\/a>.\n<\/p>\n

Installation<\/h2>\n

The installation of AutomatedLab is very easy. You can find the information you need on Microsoft TechNet: AutomateLab<\/a>. The download consists of one .msi file.<\/p>\n

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.<\/p>\n

\"Image<\/a><\/p>\n

In time, the Lab Sources<\/strong> folder can grow quite large, so you might want to choose a drive other than drive C.<\/p>\n

\n Note\u00a0 <\/b>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).<\/b>\n<\/p>\n

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.<\/p>\n

In your documents folder, you will find the sample scripts and the documentation. \u00a0The folder names are AutomatedLab Sample Scripts and AutomatedLab Documentation.<\/p>\n

An important part is the folder hierarchy of Lab Sources<\/strong>. (The purpose of this folder was explained in AutomatedLab Tutorial Part 1: Introduction to AutomatedLab<\/a>.)<\/p>\n

\"Image<\/a><\/p>\n

Installation done.<\/p>\n

Prerequisites for installing the first lab<\/h2>\n

Three requirements need to be verified, before a lab can be created:<\/p>\n

    \n
  1. \n AutomatedLab requires Hyper-V in Windows Server\u00a02012\u00a0R2 or Windows\u00a08.1\n <\/li>\n
  2. \n The ISO files to be used during creation of the lab need to be present in \\LabSources\\ISOs.\n <\/li>\n
  3. \n Windows PowerShell remoting needs to be enabled on the host machine.\n <\/li>\n<\/ol>\n

    The first thing to do is to acquire ISO files for Windows Server\u00a02012\u00a0R2 and Windows\u00a08.1. The ISO files must provide a Standard or Datacenter version of Windows Server\u00a02012\u00a0R2 and a Professional or Enterprise version of Windows\u00a08.1.<\/p>\n

    If you want to know which operating system versions your ISO files contain, use the following command:<\/p>\n

    \n Get-LabAvailableOperatingSystems -Path <\/p>\n

    \"Image<\/a><\/p>\n

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

    Open an elevated command prompt in Windows PowerShell and type the command Set-LabHostRemoting<\/strong>.\u00a0The output looks like this:<\/span><\/p>\n

    \n VERBOSE: starting log\n<\/p>\n

    \n VERBOSE: Set-LabHostRemoting Entering… )\n<\/p>\n

    \n VERBOSE: Remoting is enabled on the host machine\n<\/p>\n

    \n WARNING: TrustedHosts does not include ‘*’. Replacing the currernt value ” with ‘*’\n<\/p>\n

    \n VERBOSE: Local policy ‘Computer Configuration -> Administrative Templates -> System -> Credentials Delegation -> Allow Delegating Fresh Credentials’\u00a0configured correctly<\/span>\n<\/p>\n

    \n VERBOSE: Local policy ‘Computer Configuration -> Administrative Templates -> System -> Credentials Delegation -> Allow Delegating Fresh Credentials’\u00a0configured correctly<\/span>\n<\/p>\n

    \n VERBOSE: Set-LabHostRemoting…leaving.\n<\/p>\n

    Note\u00a0 **Because running the command **Set-LabHostRemoting<\/strong> sets TrustedHosts<\/strong> to \u2018*\u2019<\/strong>, 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<\/strong>.
    \nTo modify trusted hosts:<\/p>\n

    \n 1. Opening gpedit.msc, go to Computer Configuration > Administrative Templates > System > Credentials Delegation.
    2. Modify the following policies: Allow delegating fresh credentials<\/strong> and Allow delegating fresh credentials with NTLM-only server authentication<\/strong>.
    <\/span>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.<\/span>\n<\/p>\n

    Create the first lab<\/h2>\n

    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.<\/p>\n

    Basic metadata information<\/h3>\n

    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<\/strong> 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.<\/p>\n

    \n Note\u00a0 <\/b>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).
    <\/b>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).<\/b>\n<\/p>\n

    In the following example, Lab Sources<\/strong> (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):<\/p>\n

    \n $labSources = ‘E:\\LabSources’ #here are the lab sources\n<\/p>\n

    \n $vmDrive = ‘D:’ #this is the drive where to create the VMs\n<\/p>\n

    \n $labName = ‘FirstLab’ #the name of the lab, virtual machine folder and network switch\n<\/p>\n

    \n #create the folder path for the lab using Join-Path\n<\/p>\n

    \n $labPath = Join-Path -Path $vmDrive -ChildPath $labName\n<\/p>\n

    \n #create the target directory if it does not exist\n<\/p>\n

    \n if (-not (Test-Path $labPath)) { New-Item $labPath -ItemType Directory | Out-Null }\n<\/p>\n

    Define the lab<\/h3>\n

    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<\/strong>.<\/p>\n

    The following command will create a new lab definition:<\/p>\n

    \n New-LabDefinition -Path $labPath -VmPath $labPath -Name $labName -ReferenceDiskSizeInGB 60\n<\/p>\n

    Define the network<\/h3>\n

    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:<\/p>\n

    \n #define the network\n<\/p>\n

    \n Add-LabVirtualNetworkDefinition -Name $labNetworkName -IpAddress 192.168.81.1 -PrefixLength 24\n<\/p>\n

    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<\/p>\n

    \n Note\u00a0 <\/b>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.<\/b>\n<\/p>\n

    Define domains<\/h3>\n

    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.<\/p>\n

    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.<\/p>\n

    \n #domain definition with the domain administrator account\n<\/p>\n

    \n Add-LabDomainDefinition -Name test1.net -AdminUser administrator -AdminPassword Password1\n<\/p>\n

    Add ISOs to the lab<\/h3>\n

    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<\/strong> switch. The Name<\/strong> 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.<\/p>\n

    \n #these images are used to install the machines\n<\/p>\n

    \n Add-LabIsoImageDefinition -Name Server2012R2 -Path $labSources\\ISOs\\ en_windows_server_2012_r2_with_update_x64_dvd_4065220.iso\n<\/p>\n

    \n \u2013IsOperatingSystem\n<\/p>\n

    Choose credentials to be used to connect to machines<\/h3>\n

    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<\/strong>. This file is then used to perform the initial set up for each virtual machine.<\/p>\n

    **Disclaimer\u00a0 **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.****<\/p>\n

    \n #these credentials are used for connecting to the machines. As this is a test lab we use clear-text passwords\n<\/p>\n

    \n $installationCredential = New-Object PSCredential(‘Administrator’, (‘Password1’ | ConvertTo-SecureString -AsPlainText -Force))\n<\/p>\n

    Define roles<\/h3>\n

    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:\u00a0<\/span><\/p>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
    \n

    \n RootDC\n <\/p>\n<\/td>\n

    		\n

    \n Root domain controller for a domain\n <\/p>\n<\/td>\n<\/tr>\n

    \n

    \n FirstChildDC\n <\/p>\n<\/td>\n

    		\n

    \n First child domain controller for a domain\n <\/p>\n<\/td>\n<\/tr>\n

    \n

    \n DC\n <\/p>\n<\/td>\n

    		\n

    \n Additional domain controller for a domain\n <\/p>\n<\/td>\n<\/tr>\n

    \n

    \n DHCP\n <\/p>\n<\/td>\n

    		\n

    \n DHCP server role\n <\/p>\n<\/td>\n<\/tr>\n

    \n

    \n FileServer\n <\/p>\n<\/td>\n

    		\n

    \n File Server role\n <\/p>\n<\/td>\n<\/tr>\n

    \n

    \n WebServer\n <\/p>\n<\/td>\n

    		\n

    \n Web Server role (all web role services)\n <\/p>\n<\/td>\n<\/tr>\n

    \n

    \n SQLServer2012\n <\/p>\n<\/td>\n

    		\n

    \n SQL Server 2012 with default instance\n <\/p>\n<\/td>\n<\/tr>\n

    \n

    \n Exchange2013\n <\/p>\n<\/td>\n

    		\n

    \n Exchange Server 2013\n <\/p>\n<\/td>\n<\/tr>\n

    \n

    \n Orchestrator\n <\/p>\n<\/td>\n

    		\n

    \n System Center Orchestrator 2012\n <\/p>\n<\/td>\n<\/tr>\n

    \n

    \n CaRoot\n <\/p>\n<\/td>\n

    		\n

    \n Enterprise or standalone Root Certificate Authority
    (Windows Server\u00a02012 or Windows Server\u00a02012\u00a0R2)\n <\/p>\n<\/td>\n<\/tr>\n

    \n

    \n CaSubordinate\n <\/p>\n<\/td>\n

    		\n

    \n Enterprise or standalone subordinate certification authority
    (Windows Server\u00a02012 or Windows Server\u00a02012\u00a0R2)\n <\/p>\n<\/td>\n<\/tr>\n

    \n

    \n Office2013\n <\/p>\n<\/td>\n

    		\n

    \n Microsoft Office 2013\n <\/p>\n<\/td>\n<\/tr>\n

    \n

    \n DevTools\n <\/p>\n<\/td>\n

    		\n

    \n Visual Studio 2013 and Visual Studio 2012\n <\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

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

    This information is specified by using a Properties<\/strong> 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.<\/p>\n

    In our case, the validation component makes sure that the ForestFunctionalLevel<\/strong> and DomainFunctionalLevel<\/strong> parameters are defined, and that they are not higher than the version of the operating system of the machine.<\/p>\n

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

    \n $role = Get-LabMachineRoleDefinition -Role RootDC -Properties @{ DomainFunctionalLevel = ‘Win2012R2’; ForestFunctionalLevel = ‘Win2012R2’ }\n<\/p>\n

    Define a lab machine<\/h3>\n

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

    Furthermore, it can be specified that the machine is to be domain-joined, will be in the domain test1.net<\/strong>, 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<\/strong>.<\/p>\n

    Next, you need to provide the installation credentials. These credentials will be required to connect to the machine later for doing administrative tasks.<\/p>\n

    The ToolsPath<\/strong> 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.<\/p>\n

    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.<\/p>\n

    \n Add-LabMachineDefinition -Name S1DC1 `\n<\/p>\n

    \n \u00a0\u00a0\u00a0 -MemoryInMb 512 `\n<\/p>\n

    \n \u00a0\u00a0\u00a0 -Network $labNetworkName `\n<\/p>\n

    \n \u00a0\u00a0\u00a0 -IpAddress 192.168.81.10 `\n<\/p>\n

    \n \u00a0\u00a0\u00a0 -DnsServer1 192.168.81.10 `\n<\/p>\n

    \n \u00a0\u00a0\u00a0 -DomainName test1.net `\n<\/p>\n

    \n \u00a0\u00a0\u00a0 -IsDomainJoined `\n<\/p>\n

    \n \u00a0\u00a0\u00a0 -Roles $role `\n<\/p>\n

    \n \u00a0\u00a0\u00a0 -InstallationUserCredential $installationCredential `\n<\/p>\n

    \n \u00a0\u00a0\u00a0 -ToolsPath $labSources\\Tools `\n<\/p>\n

    \n \u00a0\u00a0\u00a0 -OperatingSystem ‘Windows Server 2012 R2 SERVERDATACENTER’\n<\/p>\n

    The first machine is now defined.<\/p>\n

    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.<\/p>\n

    \n Add-LabMachineDefinition -Name S1Server1 `\n<\/p>\n

    \n \u00a0\u00a0\u00a0 -MemoryInMb 512 `\n<\/p>\n

    \n \u00a0\u00a0\u00a0 -Network $labNetworkName `\n<\/p>\n

    \n \u00a0\u00a0\u00a0 -IpAddress 192.168.81.20 `\n<\/p>\n

    \n \u00a0\u00a0\u00a0 -DnsServer1 192.168.81.10 `\n<\/p>\n

    \n \u00a0\u00a0\u00a0 -DomainName test1.net `\n<\/p>\n

    \n \u00a0\u00a0\u00a0 -IsDomainJoined\n<\/p>\n

    \n \u00a0\u00a0\u00a0 -InstallationUserCredential $installationCredential `\n<\/p>\n

    \n \u00a0\u00a0\u00a0 -ToolsPath $labSources\\Tools `\n<\/p>\n

    \n \u00a0\u00a0\u00a0 -OperatingSystem ‘Windows Server 2012 R2 SERVERDATACENTER’\n<\/p>\n

    Export the lab<\/h3>\n

    After configuring all the lab definitions, you can export the lab configuration by using the Export-LabDefinition<\/strong> cmdlet. This cmdlet creates two XML files in the directory \u2018D:\\FirstLab\u2019. These files contain the configuration of the lab, which makes them persistent.<\/p>\n

    \n Export-LabDefinition -ExportDefaultUnattendedXml \u2013Force\n<\/p>\n

    \"Image<\/a><\/p>\n

    The Force<\/strong> switch overwrites existing files without asking for permission.<\/p>\n

    Install the first lab<\/h3>\n

    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<\/strong> cmdlet. By using different switches, you can activate different tasks to be performed by Install-Lab<\/em><\/strong>. The following table lists the switches that are currently available.<\/p>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
    \n

    \n Switch<\/b>\n <\/p>\n<\/td>\n

    		\n

    \n Task<\/b>\n <\/p>\n<\/td>\n<\/tr>\n

    \n

    \n NetworkSwitches\n <\/p>\n<\/td>\n

    		\n

    \n Creates the virtual switch\n <\/p>\n<\/td>\n<\/tr>\n

    \n

    \n BaseImages\n <\/p>\n<\/td>\n

    		\n

    \n Creates all parent disks\n <\/p>\n<\/td>\n<\/tr>\n

    \n

    \n VMs\n <\/p>\n<\/td>\n

    		\n

    \n Creates and configures all the Hyper-V virtual machines\n <\/p>\n<\/td>\n<\/tr>\n

    \n

    \n Domains\n <\/p>\n<\/td>\n

    		\n

    \n Starts installation of all domain controllers starting with root domain controllers, then child domain controller and additional domain controllers\n <\/p>\n<\/td>\n<\/tr>\n

    \n

    \n DHCP\n <\/p>\n<\/td>\n

    		\n

    \n Installs DHCP role on machines where this role is specified\n <\/p>\n<\/td>\n<\/tr>\n

    \n

    \n CA\n <\/p>\n<\/td>\n

    		\n

    \n Installs the Certificate Authority roles if specified\n <\/p>\n<\/td>\n<\/tr>\n

    \n

    \n PostInstallations\n <\/p>\n<\/td>\n

    		\n

    \n Starts on post installation actions\n <\/p>\n<\/td>\n<\/tr>\n

    \n

    \n SQLServer2012\n <\/p>\n<\/td>\n

    		\n

    \n Installs SQL server on machines where this role is specified\n <\/p>\n<\/td>\n<\/tr>\n

    \n

    \n Orchestrator\n <\/p>\n<\/td>\n

    		\n

    \n Installs SC Orchestrator on machines where this role is specified\n <\/p>\n<\/td>\n<\/tr>\n

    \n

    \n WebServers\n <\/p>\n<\/td>\n

    		\n

    \n Installs Web server role on machines where this role is specified\n <\/p>\n<\/td>\n<\/tr>\n

    \n

    \n Exchange2013\n <\/p>\n<\/td>\n

    		\n

    \n Installs Exchange Server on machines where this role is specified\n <\/p>\n<\/td>\n<\/tr>\n

    \n

    \n DevTools\n <\/p>\n<\/td>\n

    		\n

    \n Installs DevTools (Visual Studio) on machines where this role is specified\n <\/p>\n<\/td>\n<\/tr>\n

    \n

    \n Office2013\n <\/p>\n<\/td>\n

    		\n

    \n Installs Office 2013 where this role is specified\n <\/p>\n<\/td>\n<\/tr>\n

    \n

    \n StartRemainingMachines\n <\/p>\n<\/td>\n

    		\n

    \n Starts all remaining machines (the machines which has not yet been started)\n <\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

    Call Install-Lab<\/h3>\n

    The current lab contains only a domain controller and a member machine, so the following parameters for Install-Lab<\/strong> are needed:<\/p>\n