• Article

April 2013

Volume 28 Number 04

ALM Rangers - Simplifying the Configuration of Lab Management 2012

By Micheal Learned | April 2013

Visual Studio Lab Management, first released with Team Foundation Server 2010, is an optional service that Team Foundation Server (TFS) provides for virtualizing testing workflows. Many articles, blogs and other sources have explored the benefits and features of Lab Management in general, such as automating build-deploy-test workflows and managing test environments. For example, you can schedule an automated build deploy for your application every day and run a series of automated regression tests against the application. Lab Management also enables scenarios that help eliminate no-repro situations by enabling your testers to save the state of the environments in which bugs are found and attach the snapshot directly to TFS work items—that is, you can reproduce the exact state of the bug. You can also collect rich diagnostic data that you can attach to work items to help the developers reproduce bug conditions. For example, you can collect IntelliTrace data during a test run on a Web application. With such features, Lab Management brings automation to and drives efficiency in your testing efforts.

NOTE Make sure to download the Visual Studio ALM Rangers guide on Lab Management. This guide is packed with great guidance, scenarios and hands-on labs to help you configure and use Lab Management. The MSDN Library article “Using a Lab Environment for Your Application Lifecycle” also provides more information on these topics.

This article doesn’t rehash all the general scenarios and benefits that Lab Management provides but instead focuses on summarizing the setup and configuration of Visual Studio 2012 Lab Management, the online resources available and the various dependencies involved in bringing the myriad moving parts together in one place.

As you’ll see, many pieces work in harmony to form the Lab Management service in TFS. This article will provide you with a high-level understanding of how the various parts of Lab Management integrate to provide the service that helps you mature your testing efforts. You’ll also learn about the various technologies that enable Lab Management. Throughout the article, appropriate online documentation for the various components involved is provided. Keep in mind that the information in this article isn’t an exhaustive explanation of each step required to install and configure the components involved in TFS and Lab Management. See the MSDN Library article “Configuring and Administering Lab Management” for full documentation on how you can best implement Lab Management to suit your needs.

To start, let’s investigate the various pieces of Lab Management. You need to be aware of a few key terms that are used in this space. The term environment refers to a machine or a set of virtual machines that are used for testing. The machines can be either physical or virtual. The classic example is a client role, a Web role and a data role that are on three different machines in the same environment, as illustrated in Figure 1. There are many other examples of environment topologies, including the ability to consolidate the environment on a single machine and run each role of your application in a concise environment. The point here is that you set up the environments to match your specific configuration needs—that is, scenarios that closely emulate or mimic your production environment.

Environment for multitier application
Figure 1 Environment for multitier application

Another key term in Lab Management is template. Templates are virtual machines used to deploy multiple instances of your test environments in which all the unique information about the machine is removed and generated each time it is provisioned. For example, you can spin up multiple environments containing virtual machines for multiple testers. You can store these templates in your libraries when you need to create many test environments that need similar virtual machines, such as a client role running Windows 7 or Windows 8. You can create many active environments from the same templates, which means that you need to maintain fewer virtual machines overall.

As shown in Figure 2, which is from the Rangers Lab Management Guide, the installation and configuration of Visual Studio Lab Management can seem a bit daunting at first glance.

Installation and configuration of Visual Studio Lab Management
Figure 2 Installation and configuration of Visual Studio Lab Management (click to enlarge)

Multiple technologies are involved, and the infrastructure requirements vary based on the requirements of your users. One of the initial key hurdles administrators face can be the sheer number of technologies and concepts involved. There are a lot of moving parts to dig into, and it helps to divide them into pieces and explain each separately. Specifically, the technologies, requirements and concepts for discussing Visual Studio Lab Management can be narrowed down to the following list:

  • High-level steps for configuring Lab Management
  • Team Foundation Server
  • Microsoft Test Manager
  • System Center Virtual Machine Manager components
  • Standard environments
  • Controllers and test agents
  • Windows Server 2008 R2 or Windows Server 2012 with Hyper-V hosts
  • Upgrading Lab Management
  • Lab Management and Windows Azure scenarios

High-Level Steps for Configuring Lab Management

Several high-level steps are involved when you’re configuring Lab Management. If you intend to use only standard environments (discussed later in this article), you can configure just a test controller and not use System Center Virtual Machine Manager (SCVMM) or Hyper-V. The following list applies to SCVMM-based Lab Management environments.

  • Configure Hyper-V hosts
  • Configure SCVMM (optional; but necessary to get some key benefits of Lab Management described in this article)
  • Configure TFS to enable Lab Management
  • Connect Microsoft Test Manager to your environment for verification
  • Install a test controller

For more information, see the MSDN Library article “Configuring Lab Management for SCVMM Environments.”

Team Foundation Server

The first requirement for Lab Management is to install Team Foundation Server (TFS). The focus in this article is Team Foundation Server 2012, so let’s start there. You must have an already configured TFS environment before you can configure Lab Management. TFS enables many services that comprise the Visual Studio Application Lifecycle Management (ALM) suite. These services include version control, build automation, project management and lab management, to name just a few.

NOTE Installing and configuring TFS is beyond the scope of this article. There are numerous configuration scenarios for TFS, so be sure to consult the latest version of the TFS installation guide and the Visual Studio Team Foundation Server Planning Guide before you begin.

Lab Management doesn’t require any specific topology configuration of TFS, but most robust implementations of TFS have distributed components such as Microsoft SQL Server, the application-tier components and the build system spread out on many servers. In theory, all the components could exist on a single server, but this configuration would cause scalability issues for busy servers. To gain significant benefits from Lab Management, you also need to configure Team Foundation Build to enable rich workflows such as build-deploy-test.

After you have configured your other components with SCVMM, you need to use the TFS Administration Console to configure various settings under the Lab Management node. You enter the VMM server name and enable network isolation, a feature that allows you to run multiple copies of a testing environment concurrently. You also need to configure each Team Project Collection in TFS to use a host group and library share with SCVMM. See “Configure Lab Management for Team Foundation Server” for more details.

Microsoft Test Manager

Microsoft Test Manager (MTM) comes with the Visual Studio Test Professional, Visual Studio Premium and Visual Studio Ultimate editions of Visual Studio 2012 ALM. MTM is a tool that enables your team to plan, execute and track your testing efforts. It’s comprised of a testing center and a lab center. The lab center, which you use to manage and deploy your test environments, is pictured in Figure 3. Various users (for example, testers and developers) will have MTM installed on their individual machines to connect and manage the various testing environments in your lab environment. As a testing team, you’ll perform much of the work you do to leverage the capabilities of Lab Management inside of MTM. For more information on the new features in Microsoft Test Manager 2012, see the MSDN Magazine article “What's New in Microsoft Test Manager 2012.”

Microsoft Test Manager Lab Center
Figure 3 Microsoft Test Manager Lab Center

System Center Virtual Machine Manager Components

System Center Virtual Machine Manager (SCVMM) is a system center product used for managing Hyper-V-hosted virtual machines. The management can include storage, deployment, updates and other management activities for virtual machines and templates that run on Hyper-V hosts. SCVMM provides a platform for automating many different workflows.

The supported versions for Visual Studio 2012 Lab Management are SCVMM 2012 and SCVMM 2008 R2. Be sure to check for all updates on these technologies, including SCVMM 2012 SP1 and TFS 2012 Update 1. The SCVMM admin console is a stand-alone installation that connects to the SCVMM Server components. The admin console must be installed on each application tier of your TFS environment to enable the communication between TFS and the SCVMM server.

You also configure SCVMM to leverage library servers (shares) to store the virtual machines to be used in your Lab Management environments. These may be on dedicated machines or the SCVMM server. You need to ensure that these machines are on a gigabit network and the same network switch as your Hyper-V hosts. Your Lab Management workflows will be deploying virtual machines to Hyper-V hosts and saving virtual machines to the library servers from your Hyper-V hosts, so optimal performance is critical here.

You also need to tweak some specific Windows Remote Management (WinRM) settings to improve reliability because of the interactions between Lab Management and the Hyper-V hosts, which are different from a normal Hyper-V host scenario. You’ll also want to allow unencrypted file transfers on your library machines to boost performance for the virtual machine transfers. For more information about installing and configuring SCVMM for Lab Management, see the MSDN Library article “Configuring Lab Management for SCVMM Environments.”

Standard Environments

For some scenarios, Lab Management can be used without Hyper-V hosts. Lab Management 2012 introduced the concept of standard environments, which enable more scenarios for non-Hyper-V test environments than Lab Management 2010 did. For standard environments, you aren’t required to configure Hyper-V hosts or SCVMM for Lab Management. You will need to configure a test controller (described in the next section). You can leverage physical machines or even virtual machines hosted by another platform (such as VMware) or a mix of both. With standard environments, you do lose some of the benefits of Hyper-V hosts, such as the ability to take a snapshot of the environment when you find a bug. Also, you can’t leverage templates to deploy multiple copies of a standard environment. For a complete list of scenarios supported (or not supported) by standard environments, see the MSDN Library article “Using a Lab Environment for Your Application Lifecycle.”

Controllers and Test Agents

You use controllers and test agents to distribute and run tests on remote machines with Microsoft Test Manager or Visual Studio. The controller combined with an agent forms a rig. The agents run as services under a specific security identity you configure. You can install the components from the Visual Studio Agents media, which is located here for Visual Studio Update 1.

Rigs are not exclusive to Lab Management, and you can run tests remotely by connecting Visual Studio to a controller. There are many different scenarios for rigs, but basically the idea is to automate testing and collect more or less data on these machines to fit your testing needs. For example, you might collect certain types of data (for example, IntelliTrace data) on a Web application role in your test environment. This data would be different than the kind of data you would want for the client or a data role. Your aim is to collect the right amount of data to help diagnose issues with the applications you’re testing. Figure 4 shows how a simple test rig could be set up.   

Setup of simple test rig
Figure 4 Setup of simple test rig

The controller is typically configured on a dedicated machine and controls many test agents, which are distributed on various test machines. With Lab Management, you can have the agents installed automatically on your environments (virtual machines), removing the costly overhead of having to prep the Virtual Hard Disks ahead of time. One of the great features in Lab Management 2012 is that a single test agent is used for your lab agent, deployment and test agent. In Lab Management 2010, you needed a separate agent for each of these tasks. Both the installation and the number of necessary agents have been simplified in Lab Management 2012.

If your test machines are still running Windows XP, however, you won’t be able to use this feature—you’ll need to install your test agents manually. Support for Windows Server 2003 and Windows Server 2003 R2 is coming with Team Foundation Server 2012 Update 2, but you’ll also need to install the agents manually for those products. Lab Management 2012 also has many security scenarios for configuring communication between controller and agents. With network isolated environments, you must install the Visual Studio agents in the environment before you store the environment in your team project’s SCVMM library. See the MSDN Library article “Setting Up Test Controllers in Lab Environments” for more information.

Windows Server 2008 R2 or Windows Server 2012 with Hyper-V Hosts

You can leverage Hyper-V-enabled Windows Servers (2008 R2 and later) as hosts for the various virtual machines you’ll use for testing in Lab Management environments. You can use one or more hosts to comprise a host group, which can be used as your targets when spinning up test environments. (To use a Windows Server 2012 host, you’ll need SCVMM 2012 SP1 and Team Foundation Server Update 1, which brings in support for Windows Server 2012 and Windows 8 scenarios with SCVMM.)

These hosts are the machines that host the virtual machines used in your test environments. Depending on the size of infrastructure you need, you might require many Hyper-V hosts. To support robust environments, you obviously need hosts with sufficient RAM, CPU power, networking and storage capabilities and so on. The more horsepower your hosts have in these areas, the more efficient your Lab Management environment will be. In a setup that consists of multiple machines, you should also have a fast network connection when you’re deploying from your library machines to your hosts.

Upgrading Lab Management

If you’re upgrading from Team Foundation Server 2010 to Team Foundation Server 2012, you must upgrade the various components of Lab Management. This process involves four basic steps:

  1. Upgrade test controllers You must upgrade your test controllers, which requires that you follow particular steps so that you don’t lose configuration information. See the MSDN Library article “Upgrading Test Controllers from Visual Studio 2010” for detailed instructions.
  2. Upgrade lab environments You must upgrade your agents in the various lab environments to Visual Studio 2012 agents. See the MSDN Library article “Upgrading Lab Environments from Visual Studio 2010” for details on the steps required.
  3. Upgrade build-deploy-test workflows You need to change your build templates to use the new workflow templates. This simple process is documented in the MSDN Library article “Upgrading Build, Deploy, and Test Workflow Definitions from Visual Studio 2010.”
  4. Upgrade to SCVMM 2012 (optional) Team Foundation Server 2012 and Lab Management 2012 support SCVMM 2008 R2 or SCVMM 2012, so this step isn’t necessarily required. You can upgrade to SCVMM 2012 by following the instructions in the MSDN Library article “Upgrading SCVMM 2008 R2 to SCVMM 2012.”

Lab Management and Windows Azure Scenarios

Windows Azure is the Microsoft cloud computing platform, and there are continuous updates to the service and the way it is being integrated with other technologies. Depending on your needs, Visual Studio Lab Management can require significant infrastructure in the form of virtual machines that compose environments. The scalability of the cloud, which in theory can provide unlimited capacity, combined with Lab Management scenarios that sometimes drive hungry capacity needs, makes the cloud and Lab Management logical partners.

Team Foundation Service is the Windows Azure form of Team Foundation Server. Team Foundation Service doesn’t currently have Lab Management as a feature. Because Lab Management provides standard environments to use non-Hyper-V hosted and SCVMM managed environments, however, there are scenarios in which you can integrate some workflows from the on-premise Team Foundation Service and Lab Management with Windows Azure. See this blog as an example of using Lab Manager 2012 with Windows Azure. In essence, you can integrate continuous deployment and testing scenarios to Windows Azure–hosted virtual machines. As mentioned earlier, standard environments don’t offer all the benefits of Lab Management (for example, snapshots on the environments).

Microsoft has now released support for IaaS (infrastructure as a service), which allows you to host your own virtual machines, and new Virtual Private Networking capabilities that further enable using Lab Management with Windows Azure. As with all things cloud computing, the story of Lab Management with Windows Azure is continually evolving, so be sure to stay up to date on this subject.

Summary

Now that you have a basic understanding of each technology component involved with Lab Management, you can understand how the components integrate to form the service. Team Foundation Server is the backbone that enables many of the ALM services, such as version control, project management and testing, on the Visual Studio ALM platform.

To maximize the benefits of Lab Management, you need to have a functioning TFS environment that is integrated with a SCVMM system that stores and deploys the various virtual machines into test environments. To take advantage of the various workflow possibilities with Lab Management, you need to leverage Windows Server Hyper-V hosts. The users of Lab Management—testing and development teams—leverage Microsoft Test Manager on their clients to connect to and use the lab environments. You’ll want to use Team Foundation Build to automate various build-deploy-test workflows with these environments.

There are numerous examples of the benefits of using Visual Studio Lab Management, such as automated testing, isolated test environments and snapshotting environments to help developers reproduce bugs. The various technology pieces described in this article integrate to orchestrate and automate the various testing scenarios in a powerful way.

To reiterate what I said at the beginning of this article, configuring Lab Management can seem daunting at first. But don’t be put off by the complexity. Just break down the various components and technologies involved into smaller pieces during your planning. And consult the extensive documentation available as you roll out your setup.

Happy testing!

Micheal Learned is a senior premier field engineer developer with Microsoft and works as a Visual Studio ALM Ranger project lead. He focuses on helping Microsoft customers with .NET Framework development and application lifecycle management. He can be reached on Twitter at twitter.com/mlhoop.

Thanks to the following technical experts for reviewing this article: Mike Fourie, Ed Blankenship, Jelle Druyts, Krithika Sambamoorthy, Willy-Peter Schaub, Richard Fennell and Hosam Kamel.