Summary: Microsoft PFEs, Raimund Andree and Per Pedersen, present a multipart series about using Windows PowerShell to deploy a solution called AutomatedLab.
Microsoft Scripting Guy, Ed Wilson, is here. Today we kick off a multiple part series about automated lab deployment by using Windows PowerShell. Written by two Microsoft premier field engineers, Raimund Andree and Per Pedersen, this series focuses on lots of good stuff, and it culminates with a way cool Windows PowerShell script. This is a series you do not want to miss.
I am a premier field engineer working for Microsoft Customer Services and Support. From the beginning, I was caught between development and system administration. We now have a term for that: DevOps. I started in system administration with Novell 3.11, and in development with COBOL and RPG on IBM Mainframe. But I always had more fun working with Microsoft technology. My primary technical focus area is automation, mainly with Windows PowerShell and C#, and sometimes graphically with Orchestrator. When I am not scripting and programming, I am delivering Windows PowerShell workshops, offering side-by-side coding assistance, or providing code reviews. Other technical areas of interest for me are Windows Azure and Active Directory.
I am a platforms premier field engineer working for Microsoft Services, which delivers customer support—both proactive and reactive. I originally came from a developer and scripting/automation background, but I have been working with the Microsoft infrastructure for the last 20 years. Some of my primary deliveries are Windows PowerShell workshops, side-by-side Windows PowerShell help, talks about various peripheral areas where Windows PowerShell plays a role (such as in Microsoft Azure and Office 365), and recommendations about Windows PowerShell and coding best practices. Other main areas of my work include PKI, Active Directory, networking (IPv4 and IPv6), DirectAccess, and network/performance troubleshooting. Secondary areas include Hyper-V and System Center Configuration Manager.
Today they discuss the architecture of AutomatedLab…
We all know the situation: Your company wants to upgrade some software product or wants to introduce something new, and you need to test this in a lab environment that looks somewhat similar to your production environment.
Let’s say you need to test the integration of a software product with Active Directory. No big deal. You install a hand full of servers. Because you have more to do than watch the installation process, you take care of a lot of other tasks while setting up the lab. While you are taking care of these often undocumented tasks, you might miss one or two important settings for your installation—settings that you cannot change, for example, the forest functional level or domain name.
Now, you need to start from the beginning and invest even more time. Or even worse, you do not realize that something went wrong with the setup, and you end up with unreliable test results.
It is a best practice to automate these processes as much as possible. It is faster, more efficient, and (what might be even more important), more reliable. If you run a script two times, you will get the same result two times. However, if you set up a lab with five machines more than once, it is quite possible that these labs will have some differences.
The people working on AutomatedLab are consultants and field engineers who work with very different customers. On several occasions, we need to write code based on specific infrastructure requirements, or we have to troubleshoot a certain issue. Obviously having only one test environment does not work. There are too many different designs, software versions, and customer specific configurations. Hence, setting up labs to include all of these parameters can be quite time consuming.
What AutomatedLab includes
AutomatedLab is a solution to help you install a lab scenario in a very short time, with the complexity of your choice. For example, setting up a domain with a single server or client takes about 15 minutes. Setting up a big lab with more than 10 machines takes about 1.5 to 2 hours (largely depending on the speed of your disk). You can specify all the important settings, such as names, IP addresses, network configuration, operating system version, and forest functional level. You can also assign roles to machines like IIS, Exchange Server, or domain controller. Installation of any machine with any role in AutomatedLab, is of course, unattended.
To enable you to get started quickly, AutomatedLab comes with a bunch of sample installation scripts that cover very different scenarios. There are sample installation scripts for simple things like single clients or domains with only one member machine. Also, there are sample installation scripts that install Exchange Server 2013, SQL Server 2012, Orchestrator 2012, a client with Visual Studio 2013, and a web server. Imagine how long it would take to install all of this manually. AutomatedLab does it in about 2 hours on an SSD drive.
Note The purpose of AutomatedLab is for installing lab and test environments. It is not meant for production scenarios.
How AutomatedLab works
AutomatedLab is provided as an .msi file. The file includes Windows PowerShell modules, sample scripts, documentation, and lab sources.You can find the information you need on Microsoft TechNet: AutomateLab.
Windows PowerShell modules
90% of AutomatedLab is pure Windows PowerShell script. However, some code had to be done in C#. Windows PowerShell modules provide a nice and easy way to create script packages. If you need more information about how Windows Powershell modules work, take a look at about_Modules.
AutomatedLab comes with seven Windows PowerShell modules, which will be discussed in more detail later in this post. These modules need to be in the correct path to get automatically loaded. The default location of Windows PowerShell modules that are being installed is in the WindowsPowerShell folder of the Documents folder of the Windows user who is installing AutomatedLab.
There are a number of sample scripts that demonstrate the capabilities of AutomatedLab. You may have to change a sample script prior running it to make it work on your machine. Each sample script looks for a folder called LabSources on drive E, and it tries to install the virtual machines on drive D. Please change these drives to match the drives in your computer.
Of course, you can also remove or add machines. This requires minimal knowledge of Windows PowerShell, but it is merely copying and pasting the calls to Add-LabMachineDefinition and changing the parameters to the values of your choice.
Yes, this is the explanatory documentation. By default, this is copied to the Documents folder of the Windows user who is installing AutomatedLab.
This is a folder hierarchy that is created by the installer to provide all the sources for installing a lab environment. The sources include:
Place all ISO images referred to in the installation script in this folder. If you download images from MSDN or other sources, the names may vary. So please make sure you change the installation script accordingly.
AutomatedLab comes with some built-in, role-dependent post-installation activities. These include creating Active Directory users, installing the well-known sample databases on SQL Server, and creating trust relationships between all installed Active Directory forests. How to write your own post-installation activities will be explained later.
AutomatedLab provides you with an easy way to install software on some or all lab machines. All you need to know is how to install it silently. For example, to install Notepad++ on all lab machines, you need two lines of code and a copy of the installer executable for Notepad++ in this folder.
AutomatedLab can copy a folder to the virtual machine while creating it. By default, AutomatedLab will install the SysInternals tools on each virtual machine by using this Tools folder. Everything you put in here is going to be copied to each virtual machine (to the folder C:\Tools of the virtual machine). The next posts will tell more about this.
Windows PowerShell modules
AutomatedLab comes with seven Windows PowerShell modules. Why do we have seven modules and not only one like most products? We have tried to separate the solution into its main building blocks. This makes the coding and troubleshooting easier.
The next post will explain how to use the cmdlets in each Windows PowerShell module. (This post gives you an overview, but it is not explaining how to create your own lab.)
Let’s discover the Windows PowerShell modules one-by-one.
This module is for gathering your requirements. It contains cmdlets for defining domains, machines, roles, virtual network adapters, ISO images, and post-installation activities. AutomatedLab is based on .xml files. However, the cmdlets provided with AutomatedLabDefinition enable you to define the desired configuration by using PowerShell cmdlets. Hence, no XML knowledge is required. If you need to make it persistent, when the configuration is complete, you can export it to an .xml file.
This is the main module. It starts all the actions based on the configuration you have created (and exported to a lab .xml file) with AutomatedLabDefintion. After this export, AutomatedLab needs to import the lab .xml file. This task is performing a number of validations to make sure the specifications are valid (such as checking for duplicate names or IP addresses and making sure that all specified paths are valid). If all validations are successful, the actual lab installation can be started. All the details will be discussed in the next post.
The actual installation of the operating systems is performed by using a classic unattended setup. This is based on an .xml file that contains the machine details. AutomatedLabUnattended modifies the standard .xml file and is used only internally. There is no meaningful use case outside AutomatedLab.
We have tried to separate the main parts of the solution into two modules. AutomatedLab is based on .xml files, and it has connections to most of the other Windows PowerShell modules, whereas AutomatedLabWorker is more independent and handles workloads. These workloads are triggered by functions of AutomatedLab. AutomatedLabWorker does not have any relationships with the .xml files or the intelligence built around the lab.
AutomatedLab is heavily based on Windows PowerShell remoting (this will be explained later). Windows PowerShell remoting needs proper name resolution. Because we are creating labs, we cannot use the corporate DNS. Furthermore, we do not want the lab machines in DNS. That’s why AutomatedLab uses the good old hosts file to make sure it can contact the machines. The names of the lab machines, and thereby, the entries in the hosts file, are short names (not fully qualified domain names). This is to avoid using Kerberos protocol when authenticating to the lab machines.
Any time AutomatedLab copies something to a lab machine, it uses Windows PowerShell remoting, never SMB. This module is based on some functions by Lee Holmes.
This module does verbose logging and also writes all messages into a central location.
AutomatedLab uses differential disks to save disk space and speed up the overall installation process. This requires AutomatedLab to create the parent disks first—one disk per operating system. So if you have a lab with a 10 machines, where some machines are running Windows Server 2012 R2, some machines are running Windows Server 2008 R2, and one client is running Windows 8.1, you will have three parent disks. All virtual machines refer to one of these parent disks. When starting a lab deployment, you will see that we interact with the VHDs (that is, mount them).
Windows PowerShell remoting
AutomatedLab requires an internal or external virtual network adapter for the virtual machines to use. A private virtual network adapter is not supported because AutomatedLab on the host machine needs to be able to talk to the virtual machines.
The host creates the VHDs and the virtual machines. After starting the lab machines, they become available. And thanks to the modified hosts file, AutomatedLab can contact the virtual machines by name.
By leveraging Windows PowerShell remoting, AutomatedLab can invoke any command or script block on the lab machines. This is similar to PSExec, but more comfortable and powerful. There are lots of related resources on the Internet, but to get started, check out about_Remote and the PowerShell 2.0 remoting guide.
Following is an example of how a domain controller is installed:
- AutomatedLab creates a parent disk (if this doesn’t exist already).
- AutomatedLab creates the differential disk and the virtual machine.
- AutomatedLab starts the virtual machine and waits until the virtual machine is reachable (ICMP and WSMan).
- When the virtual machine is reachable, AutomatedLab (running on the host machine) sends the script block for domain controller promotion to the lab machine and invokes it.
- AutomatedLab waits until the virtual machine has restarted.
- AutomatedLab waits for the virtual machine to be reachable again.
That’s it. The domain controller installed.
Some actions require a lab computer to contact another lab computer. This requires a "double-hop" authentication, which is not enabled by default for security reasons. AutomatedLab uses CredSSP to make this work. For more information about CredSSP, see PowerShell 2.0 remoting guide: Part 12 – Using CredSSP for multi-hop authentication.
AutomatedLab and Windows PowerShell remoting requirements
There are a couple of things that needs to be configured on the host machine before remoting works in a lab scenario. By default, Windows PowerShell remoting uses Kerberos protocol for authentication. Kerberos protocol will not work between the host and the lab machines because a number of requirements are not fulfilled. That’s why AutomatedLab uses NTLM.
However, by default, Windows PowerShell remoting connect sonly to trusted machines. “Trusted” relates to the domain membership. However, the lab machines are either standalone or members of an Active Directory domain that is not trusted by the domain of the host machine. Hence, the TrustedHosts setting has to be modified, to allow the host machine to talk to the lab machines.
Before the lab installation can be started, the Set-LabHostRemoting cmdlet must be called. (This call is part of any AutomatedLab sample script). This function enables Windows PowerShell remoting on the host computer and sets TrustedHosts to “*”. This means that we can connect (authenticate) to any computer by using Windows PowerShell remoting. Additionally, unencrypted traffic will be allowed and CredSSP authentication is enabled so that the host computer can send the necessary credentials to the lab machines. A lab machine can pass it to another lab machine.
If you want to test something in a lab because it is dangerous, you may want to create a checkpoint first. Manually creating a checkpoint of one or two machines is not a big deal. But what if your lab contains 10 or 20 machines? Then you might want to use the functions that are provided for this: Checkpoint-LabVM and Restore-LabVMSnapshot.
These functions can create and restore checkpoints for all lab machines when you specify the All switch. If a certain checkpoint is no longer needed, you can use the function Remove-LabVMSnapshot. This is a rapid way to freeze the state of a full test lab.
Note When you plan to take a snapshot and restore domain controllers, make sure you have an understanding about USN rollback and virtualization safeguards introduced in Windows Server 2012. By default, the GenerationID feature is disabled on all domain controllers running Windows Server 2012 that are set up by AutomatedLab.
Post-installation activities and remote command execution
Post-installation activities are used to perform actions (configurations) on lab machines after the lab machines have been installed. A post-installation activity is a task that can be executed after a machine is ready and any role is installed.
A post-installation activity calls the specified script on the machine it is mapped to. You do not need to care about authentication because this is handled by AutomatedLab. If your script is based on files or needs to access an .iso file, this is automatically copied or mounted for you. The next posts will explain this in more detail.
Another cumbersome task when setting up labs is installing software on all the machines. AutomatedLab takes over this task. All you need to provide is the name of the executable (.exe) or .msi file to install. If you use an executable, you need to use a command-line parameter to switch to a silent installation. The sample scripts provide a one-liner to install the software package on all lab machines.
The next part of this series goes through the installation of a simple lab environment. You will learn about the many functions AutomatedLab provides, and by the end of the post, you will have a lab installed.
~Raimund and Per
Thanks Raimund and Per. This is way cool stuff.
I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at firstname.lastname@example.org, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.
Ed Wilson, Microsoft Scripting Guy