Visual Studio Lab Management team blog

Migrating to the Visual Studio ALM blog: http://blogs.msdn.com/b/visualstudioalm/

Charles Sterling — Tue, 10 Apr 2012 04:23:09 GMT

In an effort to reduce the number of places you need to search for ALM Content including Diagnostics, Testing and Lab Management we are combining these blogs to one location:

http://blogs.msdn.com/b/visualstudioalm/

Come on over tell us what you think!

Chuck

Lab Management walkthrough using Visual Studio 11 Developer Preview Virtual Machine

Vijay M [MSFT] — Sat, 12 Nov 2011 06:39:00 GMT

Brian Keller has published a Virtual Machine with Visual Studio 11 Developer Preview bits and described 6 hands-on-labs that can be tried in that virtual machine. In this blog post, I will show how you can use the same virtual machine in order to try out an additional walkthrough for Lab Management.

In this walkthrough, we will:

Install additional software necessary for our scenario. In particular, we will install a Test Controller in the virtual machine, and then configure the Build Controller and Build Agent.
Create a Standard Environment from Microsoft Test Manager. We will use the same virtual machine as the test machine for the standard environment.
Create a Build-Deploy-Test definition in Visual Studio, and run it on top of the environment.

Before going through this walkthrough, ensure that you have:

Downloaded and setup the virtual machine as per the instructions in Brian Keller's blog post on a Hyper-V host with an internal network. We will refer to this VM as VSALM machine in the following description.
Login to the VSALM machine as Administrator to perform the following steps.

Install additional software and create additional assets

Install and Configure the Test Controller.

Download the Visual Studio Agents 11 Developer Preview ISO to the host machine.
Mount the ISO into the VSALM machine using Hyper-V console.
From the VSALM machine, browse the DVD, and launch TestController\vstf_testcontroller.exe. Reboot if you are prompted to do so.
After the installation, launch Visual Studio Test Controller Developer Preview Configuration Tool. Configure using default settings and select the DefaultCollection from TFS. Wait for all the configuration steps to finish

Create a test case in TFS using one of the MSTest unit tests.

Open Visual Studio. open the solution for FabrikamFiber.CallCenter. Compile the solution. Open Unit test explorer, and run the unit test 'CreateInsertsCustomerAndSaves'. Using unit test explorer is covered in one of Brian's hands-on-labs.
In Visual Studio, open Team Explorer, and create a new Test Case work item. In the associated automation tab, select the FabrikamFiber.Web.Tests.CustomersControllerTest.CreateInsertsCustomerAndSaves test.
Save the test case.

Configure the Build Controller and Build Agent in the virtual machine.

Open Team Foundation Server Administration Console, and select Configure Team Foundation Build Service.
Go through the wizard. For the account to run the build service, choose .\Administrator. This is required for the build agent to be able to access the drop location.
At the end of this configuration, you should have one controller and one agent configured for builds.
Click on 'Properties' of the VSALM - Controller, and change the number of workflows that the controller can execute in parallel to "2". This required so that you can run the Build-Deploy-Test automation workflow, which in turn spawns the build workflow.

Create a Build definition in TFS to compile the FabrikamFiber solution.

From Visual Studio, select Team Explorer, and then Builds.
Create a new build definition. On the "General" tab, type in a name for the build definition - say, Fabrikam Build. On the "Build Defaults" tab, select a share where the builds should be generated. For instance, type \\vsalm\c$\drops. Ensure that you have created a folder called C:\drops, and have given "Everyone" (or atleast .\Administrator) read-write permissions to this folder. In the "Process" tab, select the Default Template. Save the build definition.
To verify that the build definition is correctly setup, queue a build, and verify that the solution compiles, and that the build output is generated in C:\drops folder. If you get a permission error, ensure that the build service hold is running under .\Administration account, and that you have given the permission to this account to access the build share.

Create an automated test plan in Microsoft Test Manager.

Open Microsoft Test Manager with elevated permissions (Shift-right-click Microsoft Test Manager in Start Menu and select Run as Administrator).
Create a new test plan called Automated Test Plan.
Add the test case created in the step above to the test plan.

Create a standard environment

Open Microsof Test Manager with elevated permissions (Shift-right-click Microsoft Test Manager in Start Menu and select Run as Administrator). Go to Lab Center.
Select "New" under Environments.
On the "Type and Name" tab, type in a name for the environment - say, Fabrikam BDT.
On the "Machines" tab, add a machine and type "vsalm" for the name of the machine. Select "Web Server" as the role of the machine.
Select "Verify". If the verification fails, ensure that you have launched MTM with elevated privileges.
Once the verifications pass, select "Finish".
The creation of standard environment takes a few minutes. During this time, the agent is automatically downloaded and installed on the machines of the environment (in this case, the vsalm machine itself). At the end of the process, you should see that the environment goes into "Ready" state.

Create and run a Build-Deploy-Test definition

Create a Test settings.

From Microsoft Test Manager, go to Lab Center, and to Test Settings.
Create a new automated test settings. On the "General" tab, type in the name of the test settings - for e.g., Fabrikam BDT Test Settings. Select "Automated". On the rest of the tabs, choose the defaults, and save the test settings.

Create a Build-Deploy-Test definition.

In Visual Studio, go to Team Explorer, and open Builds. Select "New Build Definition".
On the "General" tab, type in a name for the definition - say, BDT.
On the "Build Defaults" tab, uncheck "This build copies output files to a drop folder".
On the "Process" tab, select LabDefaultTemplate.11.xaml as the build process template.
Click "..." next to the Lab Process Settings, and enter the following settings:

Environment: "Fabrikam BDT" or the name that you gave to your environment
Build: Set the build definition to "Fabrikam Build" or the name you gave to the compilation build
Deploy: Check the option to Deploy, and Add a row in the grid. For the Machine role, select "Web Server". For the Deployment script, type "cmd /c dir". We are not really doing a deployment in this walkthrough since the application is already deployed in the virtual machine.
Test: Select the automated test plan and the test settings that you created.

Save the build-deploy-test definition,

Queue an instance of the Build-Deploy-Test definition.

Select the build definition that you just saved, and queue it. This should trigger a compilation, followed by deployment, and then the exeuction of the test cases.

What next?

In this walkthrough, you have seen how easy it was to create a standard environment. The process of installing agents onto the machines of the standard environment is automated. You also saw how you can run a build-deploy-test workflow using a standard environment. These are some of the enhancements in Visual Studio 11.

In the walkthrough, you have used the same machine for creating the standard environment. In a more realistic scenario, you would typically have test machines that you would compose into an environment. Accomplishing that using the VSALM machine can be done as follows:

Create another virtual machine with Windows 2008 R2 operating system, joined to workgroup, and present on the same Internal Network on the same Hyper-V host. We will call this virtual machine as "Test Machine" in the following description.
When you setup this machine, ensure that the Administrator's password is the same P2ssw0rd.
On the Test Machine, edit the C:\windows\system32\drivers\etc\hosts file. Add an entry <IP address of VSALM Machine> www.fabrikam.com to the hosts file. This is required for the test machine to be able to find www.fabrikam.com.
Ensure that the Network and File Sharing exception is enabled in the Firewall settings for the Test Machine.
The project that comes with the VM is an MVC project. In order to run MVC tests on the Test Machine, you need to install additional software on it. (E.g., Visual Studio with MVC3. Or, if you are like me, and are ok with the test run failing, then skip this step :). You can always do it later.).
From Microsoft Test Manager, create a new Standard environment. This time, provide the computer name of the Test Machine. In the wizard, select the 'Advanced' tab, then select the option to run Coded UI Tests. This will cause the test agent to be run using the provided account and authenticate succesfully with the test controller.
Once the environment becomes Ready, queue the same Build-Deploy-Test definition on this environment.

Lab Management in Visual Studio 11 Developer Preview

Vijay M [MSFT] — Wed, 09 Nov 2011 05:24:11 GMT

The Developer Preview that was released in Sep 2011 has a set of new features for Lab Management. Brian Harry has recently blogged about those features. The new addition in the Developer Preview is that of "Standard Environments". You can now quickly create an environment out of existing machines and use it for Build-Deploy-Test automation. You do not have to worry about manually installing agents as that is completely automated. There is one limitation with the use of Standard Environments in the Developer Preview version. The test machines that you use for creating the Standard environment must be domain-joined machines, and they must be trusted by the Test Controller machine.

Give the standard environments a try, and let us know how they work for you. Brian Harry's post on how to use standard environments for Build-Deploy-Test automation can be found here.

How to run the same test in different Lab Environments?

Ankit Saraf [MSFT] — Mon, 26 Sep 2011 11:20:00 GMT

I will try to address today a common query by lot of users of Visual Studio Lab Management on how to correctly run tests in different Lab Environments.

This requirement can be achieved by making the test code read the Server names/other configuration through environment variables:

The following post by Gautam explains the changes that will be required in the test code: http://blogs.msdn.com/b/gautamg/archive/2010/02/23/how-to-get-same-test-running-under-different-environments.aspx
Extra requirement from VS Lab Management is that, the environment variable binding should be done using the following code:

Environment.GetEnvironmentVariable("TestServer", EnvironmentVariableTarget.Machine);

Now, we need to configure our test machines to have the correct values of the environment variables, for achieving this we can do:

Set this environment variables on the test execution machine before we trigger a test run manually. This approach can be used in cases where the values will not change frequently or from environment to environment.

The values to the environment variables can be set as part of Deploy of Lab E2E Workflow. For doing this we add a deployment script to run the following command on test execution machine:

cmd /c setx /M TestServer $(InternalComputerName_testServerName)

Please refer http://msdn.microsoft.com/en-us/library/ee471614.aspx for information about Deploy and macros of Lab E2E workflow.

Note: The capability to run Lab E2E Workflow is only available for virtual environments in VS 2010. It is available for both Standard (Physical) and SCVMM environments in VS vNext.

Enter/Vote for your favorite feature suggestions - UserVoice site is here!

Darshan Desai [MSFT] — Thu, 14 Jul 2011 07:03:00 GMT

Have an idea for the product and wondering what is the best way to report it? Think something is missing and you believe it absolutely has to be there?

Well, we now have an avenue for you to add and vote for your favorite suggestions. The UserVoice site for Visual Studio is here: http://visualstudio.uservoice.com/ It is simple to enter your idea, and if a lot of people agree with you, chances are high you'll see your idea incorporated in the product.

Note that User Voice is really not the best avenue for reporting bugs in the current version of the products. http://connect.microsoft.com/visualstudio is really the best avenue for that. It’s got a direct connection to our internal bug database and increases the possibility that it will get fixed. UserVoice is really better for larger feature suggestions.

So, get started, vote for your favorite ideas, and help us make the product better!!

ALM Rangers have published Visual Studio Lab Management guidance

Vijay M [MSFT] — Fri, 24 Jun 2011 08:36:00 GMT

The ALM Rangers team has produced a comprehensive guidance for Visual Studio Lab Management.This guidance has dedicated chapters for topics such as setting up and planning a lab, creating environments, and maintaining environments. If you have questions on how to setup a small or large lab, how to plan your server and storage infrastructure, or how to patch templates regularly, this guidance has the answers.

In addition, this guidance also describes a way of creating lab-ready golden templates using VM Factory. This is an alernative to using VM prep tool, if you are familiar with the VM Factory.

Bookmark the Visual Studio Lab Management Guidance TOC blog and monitor the Visual Studio ALM Rangers blog, using tag tfslm, for the latest information on this project. Give this a try when you are planning for or using Lab Management. Give feedback on additional topics that you would like to see included in the guidance either here or at the Rangers Lab Management site.

New QFE for Visual Studio 2010 testing tools

Darshan Desai [MSFT] — Thu, 23 Jun 2011 17:40:00 GMT

A QFE for Visual Studio 2010 testing tools, which fixes some important issues faced by customers, is now available.The full list of issues fixed by this QFE can be found here and you can download this patch here. Note that Service Pack 1 (Visual Studio 2010 SP1 or Team Foundation Server 2010 SP1) is a pre-requisite for installing this patch.

Here is a summary of the list of issues fixed by the QFE, to help you decide whether you should apply the QFE:

Issue 1: When you run tests on the test agent that is installed on a computer that has Visual Studio 2010 SP1 installed, the tests may not run, and the following error message is logged:

"Attempted to access an unloaded AppDomain. (Exception from HRESULT: 0x80131014)"

Issue 2: When you run a playback of a Coded UI Test on certain Windows Presentation Foundation (WPF) controls, a Microsoft.VisualStudio.TestTools.UITest.Extension.UITestControlNotFoundException exception occurs, and then you receive the following error message:

"Search may have failed at '<name>' <control type> as it may have virtualized children. If the control being searched is descendant of '<name>' <control type> then including it as the parent container may solve the problem."

Issue 3: When you try to create a work item from the Test Results pane in Visual Studio 2010 after you connect to a Team Foundation Server (TFS) server, a System.OutOfMemory exception occurs, and the creation operation fails. This issue usually occurs if the TFS server has many builds.

Issue 4: When some tests run in a build operation, some builds that are queued in a TFS server stop responding. Additionally, the following error message is logged in the build log:

Waiting to publish...
Publishing results of test run <build name> to http://<TFS server address>:8080/tfs/DefaultCollection...
The process cannot access the file '<directory>\data.coverage' because it is being used by another process.
Publish failed or canceled.

Configuration matrix testing using Visual Studio Lab Management

Ankit Saraf [MSFT] — Thu, 26 May 2011 10:58:00 GMT

One of the common issues regularly faced by our users is how to test their application in both IE and Firefox. Visual Studio Lab Management can help in solving this issue for automated Coded UI test as part of Lab E2E Workflow flow.

To accomplish this with Lab Management, we will need

Visual Studio 2010 Feature Pack 2 (To be installed on developer box, build box, test controller and test agents)
Customized build template derived from LabDefaultTemplate. (Attached to this post)

Lab Management uses Test Settings to define the Role of the environment to use for running test and also for data collection. If there are more than one machines of the Execution role in the environment, then the tests are distributed among them. For configuration matrix testing between IE and Firefox we want to be sure that all our tests run both on IE and Firefox.

So to accomplish our goal we will be using multiple test settings and multiple automated test runs within our environment.

Let us setup the environment now, to do that we do the following:

Create a Lab Environment for our application with the additional requirement that we add one more Web Client machine and name the roles for the two machines WebClientIE and WebClientFF.

Create two test settings by going to the test settings page in Lab Management for this environment; name them TestSettingIE and TestSettingFF. In TestSettingIE, we set WebClientIE as the execution role and enable the data collectors on other roles as required (you should disable data collectors on WebClientFF role as this machine will not participate in the test run for this test setting). In TestSettingFF, we set WebClientFF as the execution role and enable data collectors on the other roles.

Login into the WebClientFF role machine and we need to set the environment variable CodedUITestCurrentBrowser to specify to the Test Agent to run the Coded UI tests in Firefox. Restart the Test Agent process.

Make sure all other pre-requisites for deploying the application are also done and we can then take a checkpoint for our daily Lab E2E workflow build.

With these steps our environment is ready. Now we will do the setup of the test cases.

After installation of Feature Pack 2, we open our test project from source control and record a new Coded UI test. This will add the required references for running our Coded UI test against Firefox. After this we check-in our test project back to source control. (A good idea at this point will be to make sure that all tests which we plan to run on both IE and FF are run on your development box with Firefox as the execution browser to avoid any test issues later.)

Now we need to setup the build:

Please download the attached LabDefaultTemplate_ConfigTest.xaml; We need to check it in the source control in the BuildProcessTemplates directory. This template is the default Lab build template with the changes to execute two test runs. You can open the file in Visual Studio to understand the changes.

Now we define a new build and select our LabDefaultTemplate_ConfigTest as the build template (to do so you will need to select the add existing xaml option).

We enter all the parameters for the environment created earlier in this build as we normally do for Lab E2E workflow builds, the test setting selected on the Test page of the workflow parameters wizard will be ignored by our build.
We need to enter the test settings on the Process page of build under the values TestSettingRun1 and TestSettingRun2, we need to enter the values as ID of the test settings which we can get from the Test Settings page of Lab Management. We enter the ID for our TestSettingIE and TestSettingFF in the two fields.

Now we can run this build and it will go through the build, deploy & test phases. It will create and execute two test runs by the name BuildNumber & BuilNumber_2, we can check them under Test > Analyze Test Runs page of Microsoft Test Manager.

With this we have accomplished our goal of executing same set of tests on both IE and Firefox using Lab E2E workflow.

For running the test in Firefox, we used a feature introduced in Feature Pack 2 (more info) to capture Coded UI test in IE and run them in Firefox. If you want to run the configuration matrix across various versions of IE, we do not need to install Feature Pack 2, we just need to have the different versions of IE installed on the two WebClient machines we have in our environment.

You can also extend this testing to beyond two runs by modifying the build template to include more test runs and creating the additional web client machines and test settings in the environment.

Support for Windows Server 2008 R2 SP1 hosts and SCVMM 2008 R2 SP1

Vijay M [MSFT] — Mon, 28 Mar 2011 04:50:30 GMT

Both Visual Studio Lab Management 2010 and Visual Studio Lab Management 2010 SP1 work with the Windows Server 2008 R2 SP1 hosts. Windows Server 2008 R2 SP1 includes new features such as dynamic memory, which are great for test labs. Dynamic memory increases the VM density and allows you to run more VMs on the same hardware.

In order to use the new Windows 2008 R2 SP1 hosts and features such as dynamic memory, here is what you need to do:

(a) Upgrade your SCVMM server from 2008 R2 to 2008 R2 SP1.

(b) Upgrade the SCVMM admin console on TFS Application Tier machines to SCVMM Administration Console 2008 R2 SP1.

(c) Ensure that every host group in SCVMM has hosts of only one type - Do not mix Windows 2008 R2 hosts and Windows 2008 R2 SP1 hosts in the same host group.

(d) You have to set the dynamic memory value on the template in SCVMM library before importing the template into Lab management. If you already have imported templates, use MTM to delete them from all team projects, set the dynamic memory value on the templates using SCVMM admin console, and then re-import them into MTM.

(e) Now, when you create fresh environments using these templates on 2008 R2 SP1 host groups, dynamic memory value will be honored. You will not be able to see the dynamic memory values from MTM. MTM would only show the startup memory. However, you can use SCVMM admininstration console to see the memory usage of VMs.

Running Build-Deploy-Test workflow on physical environments

Darshan Desai [MSFT] — Tue, 15 Feb 2011 11:46:00 GMT

UPDATE: In Visual Studio 11, we have introduced rich support for creating physical environments (called as Standard Environments) and running build-deploy-test workflows on them. Check this blog post for details and to get started: http://blogs.msdn.com/b/lab_management/archive/2011/11/12/lab-management-walkthrough-using-visual-studio-11-developer-preview-virtual-machine.aspx The below article still holds good for Visual Studio/Team Foundation Server 2010.

DISCLAIMER: The information in this post is provided “as-is”, we make no guarantees that the steps will work reliably, and we will not provide any support or upgrade for the definitions you create using the steps described here.

Lab Management feature in Visual Studio 2010 enables automation of the build-deploy-test cycle. This scenario is supported only on virtual environments managed by Lab Management in the current release. This post talks about how this capability can be extended to run workflow on physical machines, with some limitations.

Pre-requisites

1. Create a physical environment comprising of the machines on which you want to run the build-deploy-test workflow.

Note: In Microsoft Test Manager, you’ll see the Workflow capability status as ‘Not Configured’ for all physical environments. This is OK and your workflow can still run if you follow the steps in this post.

2. Install the build service and configure a build agent on each of the machines in this physical environment. Configure all the build agents with one build controller.

Note: Do not install lab agent on these physical machines.

3. Add a tag to the build agents you configured in step #2. You can do this either from the Team Foundation Administration Console on the build agent machine, or from ‘Builds -> Manage Build Controllers’ in Visual Studio. If you do not do this, the build definitions authored using the ‘Default Template’ (to build your code) may pick this agent to run your builds (the default matching criteria is agent with no tags) – and this might not be a desirable behavior.

Steps to setup and configure the workflow

1. Download the attached zip file, extract the workflow template ‘BuildDeployTest-physical.xaml’ and check-in to source control (example: $/<projectName>/BuildProcessTemplates).

2. Follow the steps to create a build definition described here. Instead of choosing LabDefaultTemplate.xaml, choose the template that was checked-in in the above step.

Note: If the new template does not appear in the drop down, click on the ‘New’ button besides the drop-down, choose ‘Select an existing XAML file’ option and browse for the new template.

3. This definition should be run only on the build controller to which the build agents are configured.

4. Following are the important arguments to be specified for the workflow.

a. ‘Build: New Build’ section (Fill in this section to queue a new build)

Build Definition Name: Name of the build definition to be queued.
Configuration: Configuration of the build to be used for deployment and testing (ex: Debug, Retail)
Platform: Platform of the build to be used for deployment and testing (ex: x86, x64)
Queue New Build - Indicates whether new build should be queued.

b. ‘Build: Pick Existing Build’ section (This will be used only if new build is not queued)

Build Location - Path from which the build should be picked up
Build Number - Value that identifies the build. Typical format is BuildDefinitionName_Date.Revision. This is used to associate the test run with the build. This argument is optional.

c. ‘Deployment’ section

Deployment Scripts – List of scripts that perform the deployment. Each script is of the format BuildAgentName # PathToExecutable # Arguments

Example 1: Agent1 # $(BuildLocation)\install.exe # /q

Example 2: Agent2 # cmd.exe # /c copy $(BuildLocation)\install.exe C:\installer

BuildAgentName – name of the build agent on the machine where the script should be executed. You can check the build agent name from ‘Builds -> Manage Build Controllers’ in Visual Studio.

PathToExecutable – file path to the executable that needs to be executed. This can contain the macro $(BuildLocation) which will be substituted by the value of BuildLocation workflow argument.

Arguments – arguments to be passed to the executable. $(BuildLocation) macro is allowed.

2. Run deployment scripts – Indicates whether deployment should be performed.

d. ‘Test’ section:

Test Environment Name – Name of the physical environment

Test Run Parameters – Identifies the test suites whose test cases should be run along the required test configuration and test settings.

Run tests – Indicates whether tests are to be run.

Limitations

The limitations compared to LabDefaultTemplate.xaml are:

1. Ability to pick the latest successful build. This template supports queuing a new build and picking the build from a share, but not picking the latest build, given a build definition.

2. No support to specify environment variables (the macros $(ComputerName_...) and $(InternalComputerName_...)) and working directory for the scripts.

3. No support for snapshots – Given that snapshots are not applicable for physical environments, this is a difference rather than a limitation.

Refer this article to further customize the workflow template.

We hope you find this info useful. Just to remind you again, the above steps are a work-around that enable you to run the workflow on physical machines. We will not provide any support or upgrade for the definitions you create using the steps described in this post.

Enabling Host based connection for virtual environments

Hariveer Singh — Mon, 08 Nov 2010 09:18:00 GMT

Once you create/compose a virtual environment, you can connect to it for doing manual testing etc. Environment Viewer can offer you a Host based or a Guest based connection, depending on various scenarios. Refer to this MSDN article for details: http://msdn.microsoft.com/en-us/library/ee518907.aspx. In summary, host based connections are are routed through the Hyper-V hosts on which the virtual machines reside. Apart from meeting the OS requirements, you need to be an environment owner to get a Host based connection. Host-based connections are better for interacting with virtual machines when they are booting up. Also the screen resolution of the Virtual Machine is preserved in a Host-based connection. Note: there can be only one active host based connection to an environment at any point of time.

In case you want to provide Host based connection to an another user (other than the Environment owner), you can update the owner of the virtual machines. Follow these steps:

Install the Lab Management GDR on Team Foundation Server: http://support.microsoft.com/?kbid=983578. It is also recommended that you install the patch on Microsoft Test Manager (MTM) machine also.
Run the attached script using Power Shell 2.0

Usage:

.\UpdateVMOwner.ps1 -tfsurl 'http://<MyTFS>:8080/tfs/<MyCollection>' -environmentUri 'vstfs:///LabManagement/LabEnvironment/<ID>' -vmOwner '<domain\user>'

(Updates the owner of all the virtual machines in the environment)

.\UpdateVMOwner.ps1 -tfsurl 'http://<MyTFS>:8080/tfs/<MyCollection>' -environmentUri 'vstfs:///LabManagement/LabEnvironment/<ID>' -vmOwner '<domain\user>' -LabSystems 'TestVM1, TestVM2'

(you can provide comma separated list of the names of the virtual machines in the environment)

E.g.

.\UpdateVMOwner.ps1 -tfsurl 'http://abc-tfs:8080/tfs/DefaultCollection' -environmentUri 'vstfs:///LabManagement/LabEnvironment/37' -vmOwner 'contoso\elvis'

You can find the ID of environment using MTM.

After you have successfully run this script, you can check the connection type using environment viewer (shown at the bottom)

You need to remove the .txt file extenstion type of the attached script.

Does Lab Management support non-Hyper-V platforms?

Darshan Desai [MSFT] — Wed, 27 Oct 2010 13:31:44 GMT

We get a lot of questions around the support matrix for Lab Management in TFS 2010 – does it only work for Hyper-V virtual machines or with physical machines too? Can I use it with my non-Hyper-V VMs?

I will first talk about the types of environments and the support for various capabilities of Lab Management, and finally summarize this with a table.

Types of environments:

Visual Studio 2010 supports 2 types of environments – virtual and physical, which you can create using the Microsoft Test Manager.

A virtual environments is a collection of virtual machines (with network and other settings) running on Hyper-V hosts, managed by System Center Virtual Machine Manager.
A physical environment is a collection of physical machines, on which you have installed the test agent. If you have virtual machines running on a non-Hyper-V platform, you can model them as physical machines in the system. This way, you will be able to get all the capabilities available for physical environments for the non-Hyper-V environments, but not the capabilities exclusively available for virtual environments. (refer the last section in the table below).

That said; let us look at each of the scenarios/capabilities a little more closely.

1. Testing

Using Microsoft Test Manager, you can run tests on both virtual as well as physical environments. The capabilities are exactly the same here and this means that you can run automated and manual tests, and do rich diagnostic data collection from all sorts of environments – Hyper-V, non Hyper-V, and physical.

2. Build deployment

You can easily automate the build-deployment-testing workflow on Hyper-V virtual environments using the template shipped in TFS 2010 (labdefaulttemplate.xaml).

For physical environments, such a template is not available out of the box. However, since this automation is based on Windows Workflow Foundation 4.0, you can customize the template (or create your own) using the activities in the toolbox, to automate build deployment and testing on physical machines. This means you can do the same for non-Hyper-V environments as well, however note that the virtual environment specific actions (restore to snapshot/start/stop environment) will not be available for physical and non-Hyper-V environments.

3. Environment creation and management

Creating virtual machines from a template, cloning environments using network isolation, VM operations such as Start/Stop/Snapshot/Pause are exclusively available for Hyper-V based virtual environments and not available for non-Hyper-V or physical environments.

Summary

To sum up and to answer the questions asked in the beginning, Visual Studio 2010 isn’t meant only to work with Hyper-V virtual environments. A lot of integration capabilities work for physical as well as for non-Hyper-V environments, as described in this post. Here is a table that summarizes these capabilities.

I hope this clarifies your doubts. In case you have further comments/questions, please leave a comment here or reach out to us using the msdn forum.

Updated lab management videos

Darshan Desai [MSFT] — Wed, 27 Oct 2010 12:59:43 GMT

If you haven’t noticed already, we have updated the lab management videos to add a narration and have also uploaded them on msdn as part of the ‘How Do I’ series. This makes the videos a lot easier to view and to follow.

There are 7 videos in all – an overview video to give you a quick walkthrough of the product and 6 detailed walkthroughs to help you get started, all the way from setup. The old article has been updated with the new links. You can find it here.

Take a look at the videos and we hope you will find them useful.

VM Prep Tool for Visual Studio Lab Management 2010 GDR is now available!

Shankar MSFT — Wed, 08 Sep 2010 07:03:00 GMT

As you may be aware, Lab Management GDR is now available. In sync with this release, I am happy to announce that the VM Prep Tool for Visual Studio Lab Management 2010 GDR in now available at http://code.msdn.microsoft.com/vslabmgmt.

What’s new?

VM Prep Tool GDR supports installation of patches for all lab management software on the VM. Patches can be downloaded here: (http://www.microsoft.com/downloads/details.aspx?FamilyID=8406ef19-35a3-4c03-a145-08ba982f3cef&displaylang=en) All patches to be installed should be indicated in the LabVMConfig.xml (located in the same folder as VMPrepTool.exe) under the ‘PatchesFolder’ parameter. The VM Prep Tool would pick up any patch executables found in this folder and install them on the VM.

This operation is supported both in self-service/ admin mode using the VM Prep Tool UI or from the command line.

Please refer to the documentation available on the release site for details on how to setup and use the tool. Do let us know if there are questions or feedback on the tool. Previous versions of the tool will continue to be available online (under the download tab->Releases) in case someone still requires it.

Lab Management General Distribution Release is now available

Darshan Desai [MSFT] — Fri, 20 Aug 2010 06:33:55 GMT

We are happy to announce that the General Distribution Release for lab management in Visual Studio 2010 is now available. A couple of weeks back, we announced the general availability of lab management, licensing changes, and what’s changed since RC. You can review these here.

The final bits are now available for download to licensed customers. Here are the links to get the update that upgrades lab management functionality: The patch you need to install and the KB article that describes the update.

You need to install this patch on the following machines:

Team Foundation Server
Client machine (i.e. the machine running Microsoft Test Manager)
Visual Studio Test Controller
Build machines
All the virtual machines and templates that are part of your environments. The patch has updates for the agents installed on the virtual machines.

If you haven’t configured lab management already, this page has useful links to help you get started and setup lab management.

This is a great moment for the product team. We can’t wait to see you use lab management and reap the benefits. Please provide us your valuable feedback.

General Availability of Visual Studio Lab Management announced

Hariveer Singh — Wed, 04 Aug 2010 18:23:39 GMT

Today, at the Visual Studio Live event in Seattle, Dave Mendlen – Senior Director of Developer Marketing at Microsoft announced the final release of Lab Management in the Visual Studio 2010 release. We are announcing the general availability of the Lab Management capability as end of August, 2010. In addition to general availability we also announced that at the time of release, the Lab Management capability will be immediately available to all customers who have licenses for one of the following products:

Visual Studio 2010 Ultimate with MSDN, or
Visual Studio Test Professional 2010 with MSDN

In this journey to final release, we have worked with many customers and partners who are using current release candidate of Lab Management and incorporated their feedback to improve overall performance, stability, usability and diagnose-ability.

The following is a list of major fixes since release candidate

• Improved performance for Lab Management Workflow Wizard.

• Improved performance for automated test case execution on Network Isolated Lab environments.

• Fix for an issue where Test Controller service account being same as Lab Service account caused issues with environment capabilities.

• Ability to provide Host based connections to multiple users.

• Improved error messages for error conditions to help diagnose issues.

This release will be available as a single patch which you will need to apply to TFS, Visual Studio Client, and agents.

To know more about Lab Management you can visit Lab Management site at http://www.microsoft.com/visualstudio/en-us/solutions/software-quality/lab-management

To watch Lab Management videos visit http://go.microsoft.com/fwlink/?LinkId=183021

If you want to try out Lab Management scenarios, you can download a preconfigured VHD which has all lab management components installed and configured from http://go.microsoft.com/fwlink/?LinkID=195885

Now if you want to setup Lab Management for your team visit http://msdn.microsoft.com/en-us/vstudio/ee712698.aspx

Looking forward for you to try this capability and do provide us your valuable feedback.

Visual Studio Lab Management 2010 – Host group and Library Share management

Hariveer Singh — Fri, 02 Jul 2010 06:52:00 GMT

Visual Studio Lab Management 2010 setup guidelines explains the steps required for first time setup and configuration of Host group and Library share in Virtual Machine Manager server to enable the scenarios that is required for Lab management to work.

The blog here talks about some of the management activities that could be done in Virtual Machine Manager library share and Virtual Machine Manager host group and its implication in Visual Studio Lab Management 2010. In this blog, I will refer Virtual Machine Manager as VMM server.

1.0 Host group management

Out of band changes in VMM server

Any Host group level modifications done at VMM will have impact in Visual Studio Lab Management 2010.

The operations listed below will all result in loss of Lab objects created via Visual Studio Lab management 2010 when the host group is already bound to Lab Management.

Rename of host group in VMM
Movement of Host group in the VMM Host group tree
Removal and re-addition of host group in VMM

After any of the above operation, the Visual Studio Lab Management will become out of sync with VMM resulting in Lab objects like Environments created in host groups going to Failure or Missing state. Any new Lab operations like for example create on the host group will result in failure.

Removal of Host group

If you would like to remove a host group completely out of Lab Management, then all Lab objects created in the host group would have to be deleted first. You can delete the Lab objects via Microsoft Test Manager by deleting the created Environment explicitly using Delete operation.

You can also use the TFSCONFIG command to remove the data from a host group. Please note that this is not the clean way as this will only remove the host group related data from TFS however the external artefacts will continue to remain in VMM. The command to delete is as follows:

<TFS Install path>\tools\TfsConfig lab /hostGroup /collectionName:<collectionName>
[/delete /name:<name> [/noprompt]]

Once the Lab objects in Host group has been removed, then you can completely remove the host group binding with Lab Management using TFS Admin Console in Lab management tab at Collection level settings.

2.0 Library Share management

Out of band changes in VMM

Just as host group, any out of band changes at Library Share will result in loss of Lab objects created via Visual Studio Lab Management 2010.

Once Library Share has been bound to Visual Studio Lab Management 2010, the Library share cannot be removed and re-added in VMM server. Removal and Re-addition will result in Lab Management to be out of sync with VMM resulting in all Stored Environments, Imported VMs and Templates to be in Failure or Missing state. Any new Lab operations like create using Templates in those Library will result in failure.

Removal of Library Share

Similar to Host group, to remove a Library share completely from Lab Management, all the Lab objects should be removed first.

Using Microsoft Test Manager, you should delete all the imported VMs and Templates and should also delete the Stored environment templates created on that Library share. Please note that deletion of imported VMs and Templates will only remove it from Lab Management. The templates will continue to remain in VMM Library. However, if you have either created a Template via Lab Management using “Store in Library” option or if you have created a stored Environment template, then deletion of those will remove them completely from VMM Library.

The best way to think about this is, anything that was created from within Lab Management will be removed while anything that was imported from VMM server will continue to persist in VMM Library.

There is an option in TFSCONFIG that can be used to delete the Library objects. However, as mentioned earlier it is not the clean way to do so. The command line will look as below

<TFS Install path>\tools\TfsConfig lab /libraryShare /collectionName:<collection name>
[/delete /name:<name> [/noprompt]]

Once the Lab objects have been deleted, then the Library Share binding can be completely removed from Lab Management using TFS Console in Lab Management tab at Collection level settings.

3.0 Host management

Movement of Host is allowed provided the movement is within the same hierarchy in VMM host group tree. If say in VMM the Host group tree looks as below:

And lets say that in TFS you have configured your Host group binding at “All Hosts”\HG1\HG2 like as below

With such configuration, you will be able to move a host any where under HG2 sub-tree. If a host is initially under HG2 and if Lab objects were created and later if the host is moved under HG2\HG3, all Lab objects continue to work fine. The host can again be moved back from HG2\HG3 to HG2 without any issues. This is allowed because the Lab Management binding is at “All Hosts\HG1\HG2” level.

However, for this configuration, movement of a host out of HG2 sub-tree will result in loss of Lab objects. For this example, you cannot move a host which is under HG2 sub-tree to placed directly under “All Hosts” or be placed at “All Hosts”\HG1. Such a movement will result in all Lab environments created in that host ending up in Missing or Failure state.

If a host is removed and added back out of band at VMM, Lab Management will auto detect the environments that were created on the host. The only requirement is that the host has to be added back under a host group or the host group sub-tree which is bound to Visual Studio Lab management 2010.

4.0 Best Practices

Listed are few best practices while configuring Host, Host group and Library Share for best performance with Visual Studio Lab Management 2010.

Host reserve settings

Ensure that the Host reserve settings in the host added in VMM server is set appropriately. Make sure the values meet the minimum system requirement that the Host operation system demands. Having lesser value would result in sub-optimal performance of the host and the Guest VMs (the Environments created via Lab management) that are created in this host.

In VMM server, click on Host properties and pick the “Reserves” tab to make changes.

Host placement settings

Ensure that the Placement path chosen for the host has maximum disk capacity. By default it could point to your system drive which may not be the drive with maximum disk space.

In the same properties window, click on “Placement” tab to make changes.

Un-encrypted file transfer

If your Host and Library are within your test lab network and if it is safe to turn-off data encryption for the data that is being transferred on wire, then enabling un-encrypted file transfer between library and host will increase the performance during data transfer between them. Given that with Lab Management the transfer for Virtual Machines are in the order of Giga bytes, setting this option will help reduce the CPU load in Host and Library resulting in faster transfer rate.

Please note that you will have to enable this in both Library Share and Host group.

In VMM server, click on Host group properties –> “General” tab to make the changes.

In VMM server, click on Library Share properties –> “General” tab to make changes

Co-location of Library and Host in same Switch

It is strongly recommended for Visual Studio Lab Management 2010 that the Hosts and Library are connected in same LAN network with minimum 1 GB for network bandwidth. For any network speed which is lesser than 1 GB, the deployments of environment will consume additional time due to slow data transfer rate in the network resulting in sub-optimal performance in Lab environment creations.

If your project is spread across geographically, then it is strongly recommended to have Library and Host group created and co-located in each of the location. Having Library and Host spread across geography will result in data transfer across WAN impacting the deployment time of environments.

Lab Management (pre-release) 2010 Walkthrough VHD

Hariveer Singh — Thu, 01 Jul 2010 06:33:00 GMT

Updated 7/16/2012: Please note this an archived post and the Lab Management VHD has been retired and been removed from the Microsoft Downloads site.

Visual Studio Lab Management 2010 enables teams to accelerate setup/tear down and restoration of complex virtual environments to a known state for test execution and build automation. It extends build automation by automating virtual machine provisioning, build deployment and build verification in an integrated manner. It also allows testers to file rich bugs with links to environment snapshots that developers can use to recreate complex environments; effectively reducing wasted time and resources in your development and test lifecycle. A few months back, we had released a similar VHD with Visual Studio RC bits; but the new version has the following distinctions

It uses the Visual Studio RTM build, so you get the latest version to try out various scenarios.
There is an additional two-machine environment stored in the library. So you can try all the lab management scenarios in this multi-machine environment, which is closer representative of the customer’s deployment.
This VHD also contains another environment with Network Isolation capability. So you can run multiple copies of environment in parallel without any machine name/IP address conflicts.
Team Foundation Server has been configured with SharePoint and reporting services. So you can use this VHD to demo all the Application Lifecycle Management (ALM) capabilities offered by VS family of products

To enable quick evaluation of the Lab Management 2010 pre-RTM, we have created a Windows Server 2008 R2 Hyper-V based Virtual Machine (VM) that provides an all-in-one setup with pre-configured System Centre Virtual Machine Manager, Visual Studio, Team Foundation Server with Lab Management enabled. You can download this pre-configured VM from here.

This document consists of the following sections:

Setup instructions for importing this Virtual Machine (VM), configuring an internal virtual network and configuring this VM and the host machine (Estimated Time : 1 Hour)
Walkthroughs to try out following scenarios
- Provision environments quickly (Estimated Time: 30 minutes): deploying a stored Virtual Environment on the host and taking a snapshot.
- Automate the build-deploy-test cycle (Estimated Time: 30 minutes): executing an end to end workflow that covers building a sample web application, deploying it onto the virtual environment and executing Coded UI test
- File rich bug with environment snapshots (Estimated Time: 30 minutes): filing rich bugs with automatic collections environment snapshot, which can be used by developer to debug the issue
Other advanced scenarios

Overview

In order to use the Lab Management features, a physical Hyper-V host is required. The Hyper-V host is used to run both the downloaded VM (LabServer) and the virtual environments.

Machine	Type	Details
Physical Hyper-V Host	Physical	Hyper-V Host for hosting Virtual Machines listed below
LabServer (the VM you downloaded)	Virtual	Machine name: labserver.labdomain.local Domain Controller: labdomain.local, to which the physical host is joined A virtual internal network to which the physical host, the LabServer VM and Virtual Environments are connected DNS Server and DHCP Server (to provide IP addresses to machines connected to Internal Network) Team Foundation Server 2010 that runs source control, work-item tracking, test case management, build and Lab Management Visual Studio Ultimate 2010 Microsoft Test Manager 2010 System Centre Virtual Machine Manager (SCVMM) Server and Admin console
TailSpin VM Template	Virtual Template	A Windows Server 2008 R2 based Stored Virtual Machine template
TailSpin Environment	Virtual	Application and Database tier for TailSpin Application

Shown below is the diagram once the LabServer VM and the Hyper-V host are configured.

Setup Steps

Pre-requisites

Setup a clean install of Windows Server 2008 R2 on a Hyper-V capable machine with

At least 8 GB RAM
At least 60 GB free hard disk space
Enable Hyper-V role on the machine
Machine should be joined to a Workgroup (as later in the setup, you will join this host machine to a private AD)
Use this machine only for testing/evaluation purposes

In case you are not able to complete the Setup and Scenarios section within 10 days, you must first activate this VM to continue using for 180 days (trial period). Refer to Activation section for more details.

Import the virtual machine

Login to your host server using local Administrator credentials (All the steps below should be performed as administrator)
Download all the package files to this host machine.
The VM is available as a collection of self-extracting RAR files. Run the “Visual Studio Lab Management (pre-release) 2010 VHD.part01.exe”
Accept the License terms and select a folder to extract the rar package (The extraction will take ~30 minutes, and consume ~36 GB of disk space)
Click Start, point to Administrative Tools, and then click Hyper-V Manager.
From Hyper-V Manager’s Action pane (right side pane), click Import Virtual Machine.
Click Browse and select the folder LabServer (this would be under “Visual Studio Lab Management (pre-release) 2010 VHD” folder) in the Import Virtual Machine popup screen and choose the defaults.
Click Import and then click close. (Ignore the warnings, if any)
Troubleshooting Tips
1. If you are using Windows Server 2008 SP2 or import of the LabServer VM fails for other reason, you should try creating a new Virtual Machine using Hyper-V Manager, with 4 GB of RAM, and use the existing VHD (browse to the folder LabServer\Virtual Hard Disks\LabServer\.vhd)

Configuring virtual network adapters

Open Hyper-V Manager.
From the Actions menu, click Virtual Network Manager (left side pane).
Delete all Internal and Private Networks which are already present.
Create an Internal network adapter (This will be used to connect the physical host, LabServer VM and Virtual Environments)
1. Under New virtual network, select Internal and click Add.
2. The New Virtual Network page appears, give it a name (LabNetwork) and click OK.
3. You may get a warning that “Pending changes may disrupt network connectivity”, Click Yes, to Continue (you may lose network connectivity to the host for a couple of minutes)
Create an External network Adapter (this will be used for activating the virtual machine)
1. Again open the Virtual Network Manager from Hyper-V Manager.
2. Under New virtual network, select External and click Add.
3. The New Virtual Network page appears, give it a name (“External Network”) and click OK.
4. You may get a warning that “Pending changes may disrupt network connectivity”, Click Yes, to Continue (you may lose network connectivity to the host for a couple of minutes)

Launch the Virtual Machine

Once you go through the steps in Import the virtual machine to your Hyper-V manager, the virtual machine you added will be listed under the Virtual Machines pane.
Right-Click on the virtual machine and click Settings.
Select Network Adapter on the left side pane, choose LabNetwork (the internal network you created in the steps Configuring virtual networks) from the “Network” dropdown.
Do NOT change the network of the second network adapter and keep it as “Not Connected”. This network adapter will be later used to activate the windows image of virtual machine.
Double check that there are no other external facing adapters attached to your Virtual Machine. The VM has DHCP running and can interfere with your corporate network if it is not on an internal network.
To preserve the VM state and to automatically start it when the Hyper-V Host is restarted, make sure that the LabServer VM is configured with the following settings:
1. Right-Click on the LabServer VM and click Settings
2. Select Automatic Start Action on the left side pane, and check “Automatic start if it was running when the service was stopped
3. Select Automatic Stop Action on the left side pane, and check “Save the virtual machine state
4. Click OK.
Right-Click on the virtual machine and click Start.
Do not change the computer name of the LabServer VM

Virtual Machine configuration

Login to the LabServer VM using the following credentials
1. Username: Labdomain\tfsadmin
2. Password: P2ssw0rd (Capital P, Numeral 2, small s, small s, small w, numeral 0, small r, small d)
Restart the VM if the machine asks for reboot to apply the system changes.
Once the VM restarts and you login again, open Services(run services.msc) and make sure that the following services are running
1. Visual Studio Team Foundation Background Job Agent
2. Visual Studio Team Foundation Build Service Host
3. Visual Studio Test Controller
Open Control Panel -> Network and Internet -> Network and Sharing Center. Click on the “Local Area Connection x” (x could be any numeral say 4).
Click on Properties and select “Internet Protocol Version 4 (TCP/IPv4)” and click on Properties again.
In the General Tab, make sure that the network adapter has the following settings
1. IP: 10.10.1.2
2. Subnet: 255.0.0.0
3. Default gateway: 10.10.1.1
4. Preferred DNS: 10.10.1.2
5. Click Advanced and select DNS tab:
  1. DNS 10.10.1.2
  2. DNS suffix for this connection: labdomain.local
  3. Select “Register this connection’s address in DNS” and “Use this connection’s DNS suffix in DNS registration”
  4. Click OK
6. Click OK again.
  1. If you get the following message, answer Yes (This message comes up as the VM earlier had a network adapter to which same IP was assigned. But this adapter no longer exists, and hence it is OK to remove the static IP configuration for the obsolete adapter.)
Click Close and Close again.
Restart the VM after performing the above steps. This will ensure that the DNS, DHCP and AD services can recognize the new adapter correctly.
Once the VM restarts, login to the LabServer machine using the same credentials (labdomain\tfsadmin)

Hyper-V host configuration

On Hyper-V host machine, open command prompt and run ipconfig to make sure that the host’s internal network gets a DHCP address assigned to it by the VM’s DHCP server
Check the IP Address (should be 10.10.1.xxx) and that the DNS suffix should be: labdomain.local
Troubleshooting tips
1. On the host machine, use ipconfig /renew to get a new DHCP address on the host (if not already assigned)
2. Make sure that LabServer VM and the Hyper-V host are able to communicate with each other
  1. Open command prompt from the host machine and run “ping labserver”
  2. Find the host name of the Hyper-V host (run hostname from command prompt). Open command prompt from the LabServer VM and run “ping <HostName>”
3. Firewall might prevent the two machines from communicating to each other, turn off the firewall on the host and the LabServer VM.
4. To disable all firewalls on this Hyper-V host.
  1. Open Control Panel –> Check Firewall Status –> (from left side pane) Turn Windows Firewall on or off; alternatively run firewall.cpl
  2. Select “Turn off Windows Firewall (not recommended)” for each Network location settings (Domain, Home, Public etc.)
  3. Click OK
Join the host machine to the domain of the VM (labdomain.local)
1. On the Host machine, Click Start –> Computer –> Properties -> Change Settings
2. Under the Computer Name tab, click Change
3. Type the domain name: labdomain.local and click OK. In the popup, provide the following credentials.
  1. Username: Labdomain\tfsadmin
  2. Password: P2ssw0rd
Click OK and restart the Hyper-V host to apply the changes. (It is ok to restart the Hyper-V host even when the LabServer VM is running, as you had earlier configured to automatically save/start)
Troubleshooting tips
1. If the domain is not found, verify that LabServer VM and the Hyper-V host are able to communicate with each other
  1. Open command prompt from the host machine and run “ping labserver”
  2. Find the host name of the Hyper-V host (run hostname from command prompt). Open command prompt from the LabServer VM and run “ping <HostName>”
2. Firewall might prevent the two machines from communicating to each other, turn off the firewall on the host and the VM.
3. If you have changed the machine name of the host, restart it; before connecting to the domain.
Verification
1. After the restart of Hyper-V host, login and ensure that the LabServer VM is also running. If not, go into Hyper-V Manager and start the VM.
2. Connect to the LabServer VM and login using labdomain\tfsadmin. Open DNS Manager (Start -> Administrative Tools -> DNS) and verify that the host was successfully registered in the DNS. Notice that a new entry for your physical host is shown. (HyperVHost in the following image)
3. Troubleshooting tips
  1. If the host computer entry still does not show up, from an elevated command prompt on the host, run ipconfig /registerdns. Wait a few minutes and check the event viewer to see if there are errors. If not, check again in the DNS Manager to see that the host is registered.
Add labdomain\tfsadmin as an administrator on the host machine. This is needed so that TFS and SCVMM can communicate with the host.
1. Open Server Manager –> Configuration -> Local Users and Groups –> Groups -> Administrators (alternatively run lusrmgr.msc from the command prompt)
2. Add labdomain\tfsadmin into the administrators group. Provide the following credentials in the popup
  1. Username: Labdomain\tfsadmin
  2. Password: P2ssw0rd

Lab Management configuration

Make sure that all firewalls are disabled on this Hyper-V host
1. Open Control Panel –> Check Firewall Status –> (from left side pane) Turn Windows Firewall on or off; alternatively run firewall.cpl
2. Select “Turn off Windows Firewall (not recommended)” for each Network location settings (Domain, Home, Public etc.)
3. Click OK
Add the host to the SCVMM host group.
1. Login to the LabServer VM and open System Center Virtual Machine Manager (SCVMM) Admin Console.
  1. If VMM Server is not reachable, verify that the service Virtual Machine Manager is running on the VM.
2. Click “Add host” from the right side pane.
3. Complete the Add Host wizard, by providing the following details:
  1. Select Host Location
    1. Username: tfsadmin
    2. Password: P2ssw0rd
    3. Domain: Labdomain
  2. Select Host Servers
    1. Type the Computer Name as the machine name of your Hyper-V Host, and click Add.
    2. Ignore the warnings (on the bottom of wizard) and press Next
    3. If you receive a popup that Hyper-V role with be enabled, click Yes to continue
  3. Configuration Settings
    1. Host Group: “All Hosts”
    2. Check the “Reassociate host with this Virtual Manager Server” in case the host was earlier connected to another VMM Server
  4. Host Properties
    1. Create a folder on your Hyper-V host on a drive which has at least 20 GB of disk space.
    2. Type the full path of the folder you created and click Add.
  5. Review the summary and Click “Add Hosts”
4. After the job is completed, you can check the host status by clicking the “Hosts” from the left side pane in SCVMM Admin console.
5. Troubleshooting tips
  1. Make sure that you are not running SCVMM Server on the Hyper-V host.
  2. Manually install the System Center Virtual Machine Manager Agent on the Hyper-V host and try adding the host again.
Verifying that Lab Management is properly configured for the Project Collection
1. Launch Team Foundation Server Administration Console (Start -> All Programs -> Team Foundation Administration Console)
2. Select Team Project Collections (from the left side pane) -> Default Collection -> Lab Management tab -> Configure Library Shares
3. Click Verify to check if VMM Library Share is configured appropriately. A green tick mark should appear.
4. Select Host Groups tab, and click Verify to make sure that VMM Host Group (and the corresponding host) is configured appropriately. A similar green tick mark should appear.
5. Troubleshooting tips
  1. Add labdomain\tfsadmin as an administrator on the host machine

This completes the Lab setup and configuration. The subsequent sections help you to exercise various Lab Management scenarios.

Scenarios

Once you have configured the LabServer VM and the host as above, you can perform the following scenarios. These exercises are designed to enable a quick introduction to deploying a Virtual Environment, running an build-deploy-test workflow and creating a rich bug with environment snapshot.

For these scenario walkthroughs, we are using a sample web application called TailSpin, which is an online storefront for buying Airplanes. The company has decided to adopt virtualization to consolidate its hardware footprint and increase its utilization. The company decides to adopt Visual Studio 2010 Lab Management as it offers an out of the box integrated solution to leverage all the benefits of virtualization for application lifecycle management (ALM). Using Lab Management, the company is able to accelerate their software release cycle and also improve the overall quality as

Developer and testers are able to quickly provision virtual environments
Build automation is extended to environment provisioning, application deployment and testing
Testers are able to file rich bugs which include link to environment snapshot

Following artifacts have already been created to carry out the scenario walkthroughs

TailSpin sample web application checked-in to the source control
Coded UI Test cases for the application checked-in to the source control
Testing artifacts – test plan, manual and automated test cases, and test settings
Build definition for compiling the TailSpin application
An build-deploy-test workflow
A Virtual Machine Template (Windows Server 2008 R2) stored into the library. This VM templates has the following software installed
1. Build agent
2. Lab agent
3. Test agent
4. SQL Server Express 2008
5. IIS role
A stored Virtual Environment created with the above VM Template

Scenario 1: Provision environments quickly

(Estimated Time: 30 minutes)

In this exercise, the Test Lead uses Microsoft Test Manager to deploy a virtual environment that will be later used for nightly build verification.

Login into LabServer VM (labdomain\tfsadmin, P2ssw0rd)
Start Microsoft Test Manager. It will automatically connect to the TailSpin. Otherwise connect to LabServer\DefaultCollection -> TailSpin
Go to Lab Center, if you are currently under Testing Center
Click Deploy under the Environments section.
It will show Stored Environment from the Library. Select TailSpin Environment and Click Deploy.
Do not change the name of Environment as the same name has been used in end-to-end workflow definition.
The environment deployment will typically take ~20 minutes.
Once the environment is deployed, right click on the environment name and Click Start. Similarly right click on the environment name and Click Connect
This will open the Microsoft Environment Viewer to enable interaction with the virtual machines in the environment.
Login environment’s Virtual Machine using the following credentials (click Ctrl+Alt+Del from the toolbar in the Environment Viewer):
1. Username: Labdomain\tfsadmin
2. Password: P2ssw0rd
Troubleshooting tips: If you are not able to connect to the environment using environment viewer
1. Click on the System Info in the environment viewer and note the SCVMM VM Name
2. From the Hyper-V Manager on your Hyper-V Host, connect to this VM.
3. Login using the Administrator (local admin) and enable remote desktop on this Virtual Machine.
4. Now from the Microsoft Test Manager, right click on the VM in the right side pane, and click Remote Desktop
5. Provide the labdomain\tfsadmin credentials and accept any certificates
Troubleshooting tips: If you are not able to login using the labdomain\tfsadmin
1. Try to login using the local Administrator (password: P2ssw0rd)
2. From the computer properties, check if the VM is part of a Workgroup or joined to the Domain (labdomain)
3. If it is a workgroup VM: Click on the System Info in the environment viewer and note the SCVMM VM Name
4. From the Hyper-V Manager on your Hyper-V Host, select this VM, right click and open Settings.
5. Make sure that in the Ethernet Port on the left side pane, LabNetwork (Internal network you created earlier) is selected. Otherwise manually select the LabNetwork and click OK.
6. Also delete all other Internal and Private networks (except LabNetwork) from the Virtual Network Manager.
7. Using Microsoft Environment Viewer, manually join the VM to the labdomain domain (use labdomain\tfsadmin, P2ssw0rd)
8. Restart this VM and verify if you are now able to login using labdomain\tfsadmin.
Once you login, the Test Agent processes should start-up and connect to the Test controller. Make sure that the status changes to Online.
You might see that one of the capabilities (Testing or Workflow) has some errors. Click on the “Repair Testing capability” so that testing capability is configured appropriately.
After a few minutes, the Testing capability should also be in Ready State.
Disable Internet Explorer popups. This is to make sure that IE popups do not interfere with the Coded UI Tests (which will be executed later)
1. Launch Internet Explorer from the Virtual Machine in the environment.
2. In the “Set up Windows Internet Explorer 8” popup, click Next. Do NOT choose “Ask me later”, as this will later interfere with the execution of automated tests.
3. Select “Yes, turn on Suggested sites” and Click Next
4. Select “Use express settings” and click Finish.
5. Now Close the Internet Explorer.
Once, the testing and workflow capabilities are ready, Select the Snapshots tab from the left side pane in the Microsoft environment viewer
Click on the “Take Snapshot” icon and give it a name “Clean State”.
Use the same name (TailSpin Environment) as it as it has been used in end-to-end workflow definition

Scenario 2: Automate the build-deploy-test cycle

(Estimated Time: 30 minutes)

Visual Studio 2010 enables you to automate your whole build-deploy-test cycle using Lab Management, build and testing tools. This helps you to address some of the following key pain points with build-deploy-test cycles

Today the whole process is not automated and results in manual effort and issues. You preferably want to automate the whole process so that in the morning when the team comes to work, the build is generated, application is deployed on the environment and initial testing is already completed.
Confidence on daily builds deployed on the same environment is not high as changes may be left from an earlier build. You preferably want to setup the daily build on a clean environment.
Agility for debugging issues with other builds which are not currently deployed is really bad as we need to reset the environment and then deploy the build needed for debugging. You preferably want to have a one click experience to go to any build for debugging.

As part of this walkthrough you will experience how Visual Studio 2010 helps you to overcome the above challenges by running an end to end Workflow that builds the application, deploys the application on the Clean state of virtual environment and runs Coded UI Tests.

From the LabServer VM, open Visual Studio and go into Team Explorer. It should automatically connect to “LabServer\DefaultCollection -> TailSpin”.
Go to Builds -> Right Click on “BuildDeployTest-TailSpin” -> Edit build definition. This should open the build definition for editing.
Go to Process, from the left side pane and click on icon besides Lab process settings
A new wizard for changing Lab workflow parameters should open up.
Go to Environments, from the left side pane
1. From the dropdown, select the TailSpin Environment we created earlier.
2. Check the option to “Revert to a specific snapshot of the environment” and select Clean State
Click Finish and Save the build definition “BuildDeployTest-TailSpin”
Right click on the build definition “BuildDeployTest-TailSpin”, click on Queue new build.
Use the Default Options and Click Queue. (The workflow will take ~10 minutes to complete)
To see the progress of this workflow, double click on the “BuildDeployTest-TailSpin” in the Build Explorer.
The workflow performs the following activities
1. Compile/Build the TailSpin application and associated Coded UI tests
2. Revert the TailSpin Environment to the clean snapshot that you created earlier
3. Deploy the build on this environment
4. After the build has been deployed, take a post deployment snapshot.
5. Run Coded UI Tests (CUIT)
You can go to Microsoft Environment Viewer to see when Environment is either reverted to a snapshot, or Post Deployment Snapshot is taken.
Once the workflow is in the Running Tests step, you can even see the Coded UI Tests are being run in the Virtual environment. From the environment Viewer, check if TailSpin home page opens up automatically, and some pages are being navigated by the Coded UI Tests.
Once the workflow completes, it should report success if the deployment and test execution completes.
Troubleshooting tips
1. If some of the tests failed, Internet Explorer popups could have disrupted the Coded UI tests.
  1. Using environment Viewer, Revert the environment to the snapshot “Clean State”
  2. Perform the steps mentioned in the section “Scenario1: Provision environments quickly” on how to disable Internet explorer popups.
  3. Take another snapshot of the environment and give it an appropriate name (say “New Clean State”)
  4. Again perform the steps as mentioned in this scenario, and in step 5.2 choose the snapshot you just created.
2. If you see the message “The service is unavailable” in the browser, you can safely ignore this message. Hit the back button in the internet explorer and check if TailSpin application is working fine.
3. In the build report, you might see the message/error something like “Unable to add user or group labdomain\Windows-abcd123$”. You can ignore this message.
Using environment Viewer, you can now do further testing of the TailSpin application.

Scenario 3: File rich bugs with environment snapshots

(Estimated Time: 30 minutes)

Visual Studio 2010 enables testers to file rich bugs that help developer to debug the issue without wasting time in bug ping pong between developer/tester (e.g. developer claiming that a bug does not reproduce on his/her machine and wants more details e.g. system info, event logs etc.)

As part of this walkthrough you will experience how Visual Studio 2010 enables filing of rich bugs with automatic collections with each bug. Also with a bug you can create a Snapshot of the whole environment which can be used by developer to debug the issue. With Snapshot developer gets the whole environment in exactly the same state where the bug was filed.

Open Microsoft Test Manager, switch to Testing Center and select Plan tab.
Select TailSpin Test Plan and click Properties from the top.
Under the Run Settings section,
1. Under Manual runs, select
  1. Test Settings: TailSpin – Manual
  2. Test environment: TailSpin Environment
2. Under Automated runs, select
  1. Test Settings: TailSpin – Automated
  2. Test environment: TailSpin Environment
Click on Save and Close.
Now select the Test tab.
Select Manual Test Suite, under the TailSpin Test Plan
Select the test case “Validate if discount coupon is applied”, and right click and select Run
This will open Microsoft Test Runner.
Select the option “Overwrite existing action recording” and Click Start Test.
Follow the steps specified in the Test case, and for each step you can assign the result as Pass or Fail (Step 8 should Fail).
For step 1 of the test case, Click on "Connect to environment" (from the above toolbar) which will open Environment Viewer.
Click on "System Info" and copy Computer Name. Now Close the System Info dialog.
For Step4, open http://<ComputerName>/tailspin.web/default.aspx in Internet Explorer. Replace <ComputerName> with the actual machine name (without FQDN), you got from the System Info dialog e.g. open http://windows-abcd1234/tailspin.web/default.aspx
The Step 8 will fail as after adding the discount coupon, web page throws an error. Mark this step as Fail, and add an appropriate Comment.
Click on the Capture rectangular screenshot and take a screen clipping where the web page shows an error. This will automatically attach a screenshot to the test step.
As this bug may be difficult to debug for your developer, so you should take a Snapshot of your environment by clicking Take Environment Snapshot in the Microsoft Test Runner toolbar. This will automatically attach a snapshot of the environment to the test step.
Now file a bug by clicking Create a bug.
In the New Bug window, provide the Title (No Discount is applied) for the bug and Assign it to TFSAdmin.
You can check the Details, System Info tabs to see all the rich information which has been collected automatically.
Click Save and Close to create the bug.
Click Resume and follow step 10.
Click On Save and Close in the Microsoft Test Runner. You can choose to overwrite existing action recording, if you are asked for a confirmation.

As a tester you have a created a rich bug. Now let’s see how developer can easily reach the state of the environment where the bug was filed.

Open Visual Studio and connect to LabServer\DefaultCollection -> TailSpin in the Team Explorer.
Expand the Work Items -> Team Queries and double click on My Bugs
In the query results, you will see the bug which you just created.
Review the detailed information in Details, System Info, Test Cases tabs, to understand under what conditions the bug was found.
You can also see which of the test steps passed/failed.
Under the Details tab, double click on the .lvr file.
In the Connect to Environment dialog, select the option Connect to snapshot in this environment and click Connect. This will revert the environment to the exact state where the bug was filed.
Once the environment viewer opens up, you (as a developer) can easily investigate into the bug and fix it accordingly.

Activation

The evaluation period for this virtual machine image is 180 days; once the evaluation period terminates, the image should be discarded. NO EFFORT SHOULD BE MADE TO ACTIVATE THIS IMAGE after that date. Please read the following to get an idea of the risks and key things you need to know.

Guidelines on usage:

You have 10 days to activate the product. If not activated within 10 days, the system will shut down once every hour until activated.
The 180-day Trial is the full working version of the Windows Server 2008 R2 x64 Enterprise Full installation, the version most of you will be working with in your corporate environment. It will not require a product key (it is embedded with the download).
The 180-day Trial will shut down once every hour when you have reached the end of the 180-day evaluation period.

For complete use-rights, please refer to the EULA contained within this evaluation package.

Do not redistribute this image.
Do not put this image into a production environment.
It is recommended not to join this image to a corporate network.
Since this Virtual Machine is running a DHCP Server, you should not connect directly to an external network. Follow the steps in the next section on how to activate this image

Activation steps

Login to the LabServer VM using the labdomain\tfsadmin and close all other active programs.
Open Services(run services.msc), right click on DHCP Server and click Properties
Change the Startup type to Disabled. Click OK.
Open Hyper-V Manager on your Hyper-V Host; right click on the LabServer VM and click Settings
Change the Network of second adapter to “External Network” from the dropdown (the external network you created in the steps “Configuring virtual networks”). Click OK.
Troubleshooting tips
1. Open Virtual Network Manager from the Hyper-V Manager to find which of these adapters is connected to the external network
From inside the LabServer VM, open Internet Explorer, Click on Tools –> Internet Options and select Connections tab.
Click on LAN settings, Select Automatically detect settings. Click OK and OK again.
Open the Computer Properties (Start Menu -> Computer -> Properties) and click on the Activate Windows now
Under the section Windows activation, Click on the option Activate Windows online now
Troubleshooting tips
1. If you hit the Error Code 0xC004B011, the system clock may not be showing the correct time.
2. Manually update the system time and date of the your Hyper-V host and LabServer VM (according to your time zone) and try Windows activation again.
3. If you are not able to connect to internet, also provide the Proxy Server’s address in Internet Explorer (Tools -> Properties -> Connections tab -> LAN settings -> Select “Use a proxy server for your LAN…”)
Once the Windows activation succeeds, Click Close.
Open Hyper-V Manager on your Hyper-V Host; right click on the LabServer VM and click Settings
Change the Network of second Network Adapter to again “Not Connected”. Click OK.
Login to LabServer VM and open Services(run services.msc), right click on DHCP Server and click Properties
Change the Startup type to Automatic. Click OK.
Again right click on DHCP Server and click Start.

You can follow the same approach for activating the VM’s which are part of virtual environment (disabling DHCP is not required). Connect to the environment and Click System Info in the environment viewer. Note down the “SCVMM VM Name” and shutdown the environment. Using Hyper-V Manager, temporarily add an external network adapter for this virtual machine. Follow the steps similar to 7-12 mentioned in the above section to activate the image, and later remove the external adapter.

Advanced Scenarios (optional)

Scenario 4: Build-Deploy-Test workflow on a multi-machine environment

(Estimated Time: 60 minutes)

A typical application requires multiple machines to test it. E.g. a Web application has a Web Server, a Database server and a web client. Since more than one machine is likely to be used in the production, testing in similar distributed environment is very important. Using Lab Management, you can create complex environments to test multi-tier application and assign a Role (Web Server, Database Server etc.) to each machine in the environment.

In this scenario, we will be deploying on a two machine environment for testing the TailSpin application. One of the machine will act as a Web Client and the second machine hosts both the Database Server (SQL) and the Web Server (IIS).

Open Microsoft Test Manager and Go to Lab Center, if you are currently under Testing Center
Click Deploy under the Environments section.
It will show Stored Environment from the Library. Select “TailSpin multi-machine Environment” and Click Deploy.
Do not change the name of Environment as the same name has been associated in end-to-end workflow definition.
The environment deployment will typically take ~35 minutes.
Troubleshooting tips
1. If the deployment fails because of insufficient disk space, free-up some disk space on the hyper-v host machine. Also make sure that the drive which has sufficient space has been added as placement path in Virtual Machine Manager.
2. If the deployment fails because of insufficient memory, you should shut down the environment you previously created in the Scenario1, and re-try the deployment.
Once the environment is deployed, right click on the environment name and Click Start. Similarly right click on the environment name and Click Connect
This will open the Microsoft Environment Viewer to enable interaction with the virtual machines in the environment.
Login to each Virtual Machine in the environment using the following credentials (click Ctrl+Alt+Del from the toolbar in the Environment Viewer):
1. Username: Labdomain\tfsadmin
2. Password: P2ssw0rd
Once you login, the Test Agent processes should start-up and connect to the Test controller. Make sure that the status changes to Online in each machine of environment.
You might see that one of the capabilities (Testing or Workflow) has some errors. Click on the “Repair Testing capability” so that testing capability is configured appropriately.
After a few minutes, the Testing capability should also be in Ready State.
Disable Internet Explorer popups. This is to make sure that IE popups do not interfere with the Coded UI Tests (which will be executed later).
1. Launch Internet Explorer from the Web Client machine in the environment.
2. In the “Set up Windows Internet Explorer 8” popup, click Next. Do NOT choose “Ask me later”, as this will later interfere with the execution of automated tests.
3. Select “Yes, turn on Suggested sites” and Click Next
4. Select “Use express settings” and click Finish.
5. Now Close the Internet Explorer.
Once, the testing and workflow capabilities are ready, Select the Snapshots tab from the left side pane in the Microsoft environment viewer
Click on the “Take Snapshot” icon and give it a name “Clean State”. Use the same name as it as it has been used in end-to-end workflow definition
Open Visual Studio and go to Team Explorer. Go to Builds -> Right Click on “BuildDeployTest-2Tier-TailSpin” -> Edit build definition. This should open the build definition for editing.
Go to Process, from the left side pane and click on icon besides Lab process settings
A new wizard for changing Lab workflow parameters should open up.
Go to Environments, from the left side pane
1. From the dropdown, select the “TailSpin multi-machine Environment” you created earlier.
2. Check the option to “Revert to a specific snapshot of the environment” and select Clean State
Click Finish and Save the build definition “BuildDeployTest-2Tier-TailSpin”
Right click on the build definition “BuildDeployTest-2Tier-TailSpin”, click on Queue new build.
Use the Default Options and Click Queue. (The workflow will take ~10 minutes to complete)
To see the progress of this workflow, double click on the “BuildDeployTest-2Tier-TailSpin” in the Build Explorer.
The workflow performs the following activities
1. Compile/Build the TailSpin application and associated Coded UI tests
2. Revert the TailSpin Environment to the clean snapshot that you created earlier
3. Deploy the build on the multiple machines of this environment
4. After the build has been deployed, take a post deployment snapshot.
5. Run Coded UI Tests (CUIT)
You can go to Microsoft Environment Viewer to see when Environment is either reverted to a snapshot, or Post Deployment Snapshot is taken.
Once the workflow is in the Running Tests step, you can even see the Coded UI Tests are being run in the Virtual environment. From the environment Viewer, check if TailSpin home page opens up automatically, and some pages are being navigated by the Coded UI Tests.
Once the workflow completes, it should report success if the deployment and test execution completes.

Scenario 5: Network Isolation

(Estimated Time: 90 minutes)

Network Isolation enables you to run multiple copies of the environment in parallel without machine name or IP conflicts. The machines in a network-isolated environment are protected from network conflicts by using two network adapters. One network adapter is used for a private network inside the environment. The second adapter is configured by Lab Management to present a separate, unique identity to the external network.

In this scenario, we will first deploy a Network Isolated TailSpin Environment (the VM inside the environment will be a workgroup machine). Next we run a build-deploy-test workflow to deploy the TailSpin application. Then we store a copy of this environment in the library, and later create a new environment using this stored copy. Hence we will be able to run two environments with TailSpin application, where the machines have the same machine name etc.

Open Microsoft Test Manager and Go to Lab Center, if you are currently under Testing Center
Click Deploy under the Environments section.
It will show Stored Environment from the Library. Select “TailSpin Isolated Environment” and Click Deploy.
Do not change the name of Environment as the same name has been used in end-to-end workflow definition.
The environment deployment will typically take ~20 minutes.
Once the environment is deployed, right click on the environment name and Click Start. Similarly right click on the environment name and Click Connect
This will open the Microsoft Environment Viewer to enable interaction with the virtual machines in the environment.
Login environment’s Virtual Machine using the following credentials (click Ctrl+Alt+Del from the toolbar in the Environment Viewer):
1. Username: Administrator
2. Password: P2ssw0rd
Note you need to login as local administrator as the machine of this isolated environment is a workgroup machine.
Click Start, Microsoft Visual Studio 2010, Test Agent configuration Tool
Enter the username as .\administrator and Password as P2ssw0rd
Click on Apply Settings. It will ask the password of tfsadmin, provide P2ssw0rd
After few minutes, the Test Agent processes should start-up and connect to the Test controller. Make sure that the status changes to Online.
You might see that one of the capabilities (Testing or Workflow) has some errors. Click on the “Repair Testing capability” so that testing capability is configured appropriately.
After a few minutes, the Testing capability should also be in Ready State.
Disable Internet Explorer popups. This is to make sure that IE popups do not interfere with the Coded UI Tests (which will be executed later)
1. Launch Internet Explorer from the Virtual Machine in the environment.
2. In the “Set up Windows Internet Explorer 8” popup, click Next. Do NOT choose “Ask me later”, as this will later interfere with the execution of automated tests.
3. Select “Yes, turn on Suggested sites” and Click Next
4. Select “Use express settings” and click Finish.
5. Now Close the Internet Explorer.
Once, the testing and workflow capabilities are ready, Select the Snapshots tab from the left side pane in the Microsoft environment viewer
Click on the “Take Snapshot” icon and give it a name “Clean State”. Use the same name as it as it has been used in workflow definition
Open Visual Studio and go into Team Explorer. Go to Builds -> Right Click on “BuildDeployTest-TailSpin” -> Edit build definition. This should open the build definition for editing.
Go to Process, from the left side pane and click on icon besides Lab process settings
A new wizard for changing Lab workflow parameters should open up.
Go to Environments, from the left side pane
1. From the dropdown, select the “TailSpin Isolated Environment”
  you created earlier.
2. Check the option to “Revert to a specific snapshot of the environment” and select Clean State
Click Finish and Save the build definition “BuildDeployTest-TailSpin”
Right click on the build definition “BuildDeployTest-TailSpin”, click on Queue new build.
Use the Default Options and Click Queue. (The workflow will take ~10 minutes to complete)
To see the progress of this workflow, double click on the “BuildDeployTest-TailSpin” in the Build Explorer.
The workflow performs the following activities
1. Compile/Build the TailSpin application and associated Coded UI tests
2. Revert the TailSpin Environment to the clean snapshot that you created earlier
3. Deploy the build on the multiple machines of this environment
4. After the build has been deployed, take a post deployment snapshot.
5. Run Coded UI Tests (CUIT)
You can go to Microsoft Environment Viewer to see when Environment is either reverted to a snapshot, or Post Deployment Snapshot is taken.
Once the workflow is in the Running Tests step, you can even see the Coded UI Tests are being run in the Virtual environment. From the environment Viewer, check if TailSpin home page opens up automatically, and some pages are being navigated by the Coded UI Tests.
Once the workflow completes, it should report success if the deployment and test execution completes.
Troubleshooting tips
1. You might see the following message in the build report. You can ignore this message, since this machine is joined to workgroup; hence the account domain\Windows-abcd123 doesn’t exist.
  1. There is no such user or group: labdomain\Windows-abce123
  2. More help is available by typing NET HELPMSG 3783
Using environment viewer, shutdown the environment
In Microsoft Test Manager, right click on the Isolated Environment, and Click Store to Library
Enter the name as “TailSpin Isolated Environment Copy” and click Store. This step would take ~20 minutes
Once the Copy of the environment is stored, Click on Deploy again.
Select the “TailSpin Isolated Environment Copy” and Click Deploy This step will take ~20 minutes.
Once this environment is also deployed, right click on the environment name and Click Start. Similarly right click on the environment name (TailSpin Isolated Environment Copy) and Click Connect
This will open the Microsoft Environment Viewer to enable interaction with the virtual machines in the environment.
Login environment’s Virtual Machine using the following credentials (click Ctrl+Alt+Del from the toolbar in the Environment Viewer):
1. Username: Administrator
2. Password: P2ssw0rd
Note you need to login as local administrator as the machine of this isolated environment is a workgroup machine
Using environment viewer, you can now open TailSpin home page in internet explorer: http://localhost/tailspin.web/default.aspx
Similarly you can open TailSpin home page on the earlier TailSpin Isolated environment.
You can also check the same computer name of these environment (copy and original) by clicking on the System Info.

Appendix

The following table lists the details of all the artifacts in the VM

VM Machine Name	labserver.labdomain.local
Domain Name	labdomain.local
Domain Administrator	labdomain\tfsadmin, P2ssw0rd
TFS Administrator	labdomain\tfsadmin, P2ssw0rd
SCVMM Administrator	labdomain\tfsadmin, P2ssw0rd
Service account for test/build agent-controller communication	labdomain\tfsadmin, P2ssw0rd
Default SCVMM Library Share	MSSCVMMLibrary, “C:\ProgramData\Virtual Machine Manager Library Files”
Default Host Group	All Hosts
Template with agents installed	TailSpin VM Template
Stored environment in library	TailSpin Environment
TailSpin Source code	C:\Map
Sample Test Plan	TailSpin Test Plan

Setting up various topologies to test with Visual Studio Lab Management – Part 4

Hariveer Singh — Wed, 02 Jun 2010 13:51:00 GMT

In continuation with our topology series, this time we will pick a topology with multiple ATs, DTs and with Lab Environments joined to different domain for discussion. We will touch upon Lab Management specific requirements and configuration for this topology. Take a look at Part1, Part2 and Part3 for our earlier discussions on topologies.

Here is a quick recap on acronyms

Corp network – Would refer to the corp. network where TFS is hosted. A Corp network would have one or more ATs, DTs, Load balancers, Proxy, VMM server. Clients are typically connected to this network while at work.
Test network – Would refer to the network where the testing of the apps would happen. Test controller, Build controller, VMM server, VMM Library VMM hosts are present in this network. Please note that VMM server can either be in Corp network on in Test network depending on your choice.
Corp Domain – the domain controller in corp. network
Private Lab Domain – the domain controller in Private Test network.
AT – Application Tier
DT – Data Tier
VMM – System Centre Virtual Machine Manager
TC – Test controller
BC – Build Controller
BSH – Build Service Host
NLB – Network Load balancing
VM – Virtual Machine
LE – Lab environment
LS – Lab system within Lab Environment

Topology #4 – Topology with multiple ATs and DTs, load balancers and Environments joined to a different domain

This topology has multiple application tiers, named data tiers and a load balancer in its Corp network. The Test network has VMM server and its library and host group, Test and build controllers.

The interesting aspect in this topology is we have separate Corp and Lab AD that have no trust between them, however the Corp and Lab DNS have DNS forwarding configured to see the A records in other zones respectively. The test apps that are deployed for testing are joined to Lab AD.

We will also assume that in this topology the ATs, VMM server, Controller and the host are assigned static IP. It is not a requirement to have static IP for these components. All our previous topology discussions in Part1, Part2 and Part3 did not have this requirement and were assumed to use IP allotted by DHCP; we are considering static IP for this discussion just to illustrate that Visual Studio 2010 Lab Management works fine even with these configurations.

1) TFS configurations

Part2 covers multiple application tier installation and configuration with multiple named data tiers. So we will not be covering them again here.

As mentioned in Part1, and Part3, with the use of a load balancer, you will have to take care of appropriate notification URL and Lab URL. Other than that there is nothing Lab Management specific configurations that is required. I have mentioned F5 NLB here to illustrate that Lab Management can work with both hardware and software NLB mechanisms.

The App tier configuration for this topology looks as below once configured

The Lab URL settings is as below

The bindings in IIS for TFS website looks as below. You will notice that there is explicit IP, Port and SSL binding for HTTPS and default binding for HTTP.

2) Static IP

Application tiers, Data tiers, VMM server, VMM library, VMM host, Test and Build controllers can all be configured with static IP. Ensure appropriate DNS and Gateway is configured in their adapters.

For Environments created out of Golden VM templates, it is advisable to use DHCP to allot IP. Since the sysprep templates would not retain any DNS and Gateway adapter configuration settings during specialization, without a DHCP the Lab systems in the Environment will not be properly connected to network post Environment creation.

For cloning of environments with Network isolation it is mandatory to have DHCP in your Corp/Test network to successfully clone environments without IP conflicts.

3) Lab Environments joined to different domain

I would like to emphasize again that, in Visual studio 2010 Lab Management release we require TFS (AT/DT), VMM server, VMM host, VMM library, Test Controller and Build controller all be in same trusted domain. Visual Sutdio 2010 Lab Management do not support any of them being in a partially trusted or in no trust domains.

However, you can have your Lab environments created and joined to a different domain.

LE creation

You can create Lab environment out of Golden VM templates from library and have the OS profile edited to join to a domain which is other than what your client or TFS is part of. In the LE creation wizard, you will have to fill in the domain credentials and password in OS profile tab.

Clicking on “Test” after providing the credentials will show a warning as below. This warning appears if your client is in a domain that is not trusted with the domain that you filled in the OS profile. However, this is just a warning, so you should be able to proceed further by clicking “Finish” and initiate LE creation.

DNS forwarding & WINS

For a topology like what we have taken up for discussion, It is important for Lab environment to have connectivity to reach DNS in Test network to resolve its domain controller and to join the Lab AD.

It is also important for Lab environment to have connectivity with TFS and Controllers that are in Corp network for the Testing and Workflow capability to work fine.

Given these requirements, the topology for discussion is such that, there is single DHCP that allots IP to machines in Corp network (example your client) and to Lab environments created in Test network. The machines will have Corp DNS as the primary DNS as given by the DHCP. Hence both the Corp domain joined machines and Lab Domain joined machines will have Corp DNS as their primary DNS.

The TechNet article explains in detail the steps required for configuring DNS conditional forwarding.

To summarize:

The Lab environments should have DHCP IP allotment and have primary DNS as Corp DNS.
The Corp DNS should be configured to forward the requests meant for Lab DNS zones to Lab DNS.

This will ensure that build agent within Lab environment (in Lab domain) is able to resolve and reach TFS and Controller (in Corp domain) and vice versa.

Unlike Build controller, instead of using FQDN of agent machine, Test controller attempts to connect back to test agent using IPV4 address or using bare host name based on certain criteria. Using bare hostname is not a problem if both the agent and the Controller are in same domain. Since they share the same primary DNS suffix, the name resolution will not be a problem even if Controller attempts to resolve using agent’s bare host name. TechNet article explains in detail the name resolution logic when a bare host name (single-label unqualified domain name) is given.

However, in topology like ours where the Controller is in Corp domain (say Corp.com) and the Agent is in Lab domain (say Lab.com), name resolution will fail because the Controller attempts to resolve the name by adding its own primary DNS suffix (which will be Corp.com). Hence for topologies like this, you will require a WINS server so that Test Controller can resolve the Test Agent’s bare name using NetBIOS.

To summarize;

If you have Lab environments joined to different domain other than Test controller and if any one of the following criteria is true then you will need a WINS server for Test controller to resolve agent’s bare host name using NetBIOS.
- Lab environments are IPV6 capable
- Lab environments have lab systems that are multi-homed
If your above condition is true but you do not want to install WINS, then you will have to explictly configure in each of the Lab systems, and provide IP address to which the test agent will be bound to. This configuration is done in %ProgramFiles%\Microsoft Visual Studio 10.0\Common7\IDE\QTAgentService.exe.config

For all the other conditions, you don’t require a WINS. Test controller will be able to resolve the agent with the DNS or by connecting directly using IPV4.

4) Topology variations and its impact on Visual Studio 2010 Lab Management

Visual Studio 2010 Lab management will behave as given below, for the given topology variations

Isolated Test network

You cannot have Test network completely isolated from Corp network. If you have such a topology then the test agent or the build agent will not be able to talk to TFS or the Test/Build Controller which are in Corp domain. Hence you will not be able to leverage the testing and workflow capabilities in such a topology. You can however be able to operate on the Lab environment and do the basic Lab environment operations on it.

Without DNS forwarding

Even if you choose to have TFS and Controller as multi-homed and connected to Test Network in addition to Corp Network, the TFS or Controller will always attempt to resolve the agent name in their primary DNS which will be Corp DNS. Hence it is important to have the DNS forwarding configured in the primary DNS to be able to resolve the Lab DNS zones.

Different Primary DNS for Test and Corp network

In our discussion above we said that Corp DNS will be the primary DNS for both Corp domain joined machines and Lab domain joined machines. However, you may choose to have different DNS as your primary DNS in Corp and in Test networks respectively. In such cases, you will need to enable DNS forwarding in both the DNS such that TFS and Controller can consult Corp DNS to resolve Agent (in Lab DNS zone) and vice versa where Agent can consult Lab DNs to resolve TFS and Controller (in Corp DNS zone).

Planning considerations for setting up a lab managed by Visual Studio Lab Management 2010

Vijay M [MSFT] — Thu, 13 May 2010 06:08:00 GMT

[Last updated on: Jan 3, 2011]

As you plan to adopt VS Lab Management 2010 for managing your labs, you will probably have several questions on your mind such as:

How many servers do I need?
What kinds of servers should I buy?
Can I use a SAN for storage?
How much storage capacity do I need?
Can I setup everything on one big machine?
How do I setup an isolated lab?

This article provides you some guidance around these questions and points you to other resources that you can tap into. These guidelines are applicable when you plan to setup a real lab beyond demo use. For demo purposes, most of the rules can be relaxed :)

In addition to having Team Foundation Server, Test and Build Controllers, setting up a lab requires an SCVMM server, Hyper-V hosts, and (optionally) library servers.

SCVMM Server

1. Machine configuration: We recommend installing SCVMM Server on a machine with the following configuration for a lab with less than 50 VMs:

· 64 bit processor

· 4 GB memory

· 300 GB hard disk

· Windows Server 2008 R2 operating system

· All latest updates of Windows

These requirements will be higher if the number of VMs is higher.

2. Library: An installation of SCVMM server also acts as a default library server. So, the following recommendations assume that you will use the SCVMM server machine also as a library server machine.

3. Storage for library: Make sure that there is enough space on the drive that you plan to use as library. By default, the library share that is created by SCVMM is on C: drive. So, you either need to have more than 200 GB of space on C: drive or use a different drive in your machine as the library share.

4. Disk types for library: For small labs that do not plan to use library heavily, a disk with good speed will be sufficient. For larger labs with higher usage of library, RAID 5 configured disks are highly recommended. For even better performance in large labs, have multiple library servers. The storage for library can come from Direct-attached storage or from SAN. When using SAN, create a LUN to be used solely for library machine. Clustering of library machines is not supported.

5. Shared machine: If you plan to install SCVMM along with some other software on the same machine, you need to first ensure that SCVMM server can get the necessary amount of resources as described above after deducting the resource consumption of the other software. For instance, if you want to install SCVMM on TFS machine, then add the above requirements to those of TFS, and then ensure that the machine has enough capacity. All of the following additional considerations assume that you have met this basic requirement.

For SCVMM and TFS to be installed on the same machine, TFS should be running under a regular domain user account as opposed to network service account. If this is not feasible in your setup, you cannot put TFS and SCVMM on the same machine.

For SCVMM to be installed on a Hyper-V host, it is highly recommended that the disk used for storing Hyper-V hosted virtual machines is different from the disk used for library. For instance, use C: from one disk for library, and D: from another disk for Hyper-V virtual machines. SCVMM server, in this case, will be running in the primary OS in Hyper-V. So, when the primary OS is loaded, all Guest OS (VMs deployed in Hyper-V) will have performance impact. To reduce this impact, configure the host reserves for that machine by adding the Hyper-V host reserves (described in next section) to the SCVMM machine requirements mentioned earlier. Host reserves can be configured using SCVMM administration console.

6. Running in a VM: Do not run SCVMM in a virtual machine especially if you also use it as a library.

7. Networking: SCVMM should have line-of-sight visibility to TFS, hosts, and other library servers.

SCVMM should be connected to hosts through a gigabit network.

SCVMM machine should ideally be on a network from where windows updates can be automatically applied. If this is not feasible, you should plan on keeping track of Windows and SCVMM updates, and apply them manually as and when they become available.

8. Domain: SCVMM machine should be joined to a domain that has 2-way trust with the domain of TFS machine and hosts.

Hyper-V hosts

1. Machine configuration: The number of Hyper-V hosts and the capacity of each host depends on the number of VMs that you need to host in your lab. Use the simple capacity planner tool for guidance on how you can size your hosts. If you decide to setup a small lab, we recommend installing Hyper-V role on machines with the following configuration:

· Two dual-core 64 bit processors that are Hyper-V compatible

· 16 GB memory

· 300 GB hard disk space

· Windows Server 2008 R2 operating system

· All latest updates of Windows

If you have large number of VMs, and you decide to setup a small number of ‘big’ hosts, the following configuration is recommended for each host:

· Two quad-core 64 bit processors that are Hyper-V compatible

· 64 GB memory

· 1 TB hard disk space

· Windows Server 2008 R2 operating system

· All latest updates of Windows

2. Host reserves: Out of the host capacity requirements listed above, you must set aside the following resources just for the smooth functioning of the hypervisor. For a 16GB host, set aside:

a. 20% CPU

b. 2 GB memory

For a 64 GB host, set aside:

a. 30% CPU

b. 4 GB memory

These host reserves must be configured on the host using SCVMM administration console. Look for these settings under the host properties. Only the resources left on the host after deducting the host reserves can be used for virtual machines.

3. Storage for virtual machines: It is highly recommended that the partition used for virtual machine storage is different from the primary partition of Hyper-V server. Use D: for virtual machine storage and C: for primary partition. Once you decide on the virtual machine storage location, you need to configure that location in Hyper-V manager or through SCVMM administration console. In Hyper-V manager, change the Virtual Hard Disks folder and the Virtual Machines folder. In SCVMM administration console, change the Placement Path under the host properties.

4. Disk types for host: A disk with good speed is necessary. RAID 5 configured disks are highly recommended. The storage for host can come from Direct-attached storage or from SAN. With regard to SAN support, Visual Studio Lab Management 2010 does not support or leverage clustering. This would mean you cannot have a setup with VMM host clustering or create VMs that are cluster aware. However, if you decide to have your host’s disk come from a SAN drive for space and reliability needs, you will have to have separate LUNs mapped to each host. Even if the LUNs are managed by same controller, given that Visual Studio Lab Management 2010 does not leverage any of SAN functionalities, the underlying BITS copy during a virtual machine deployment will happen all the way from library to host via your LAN network.

5. Shared machine: You should not install any additional software such as TFS on your host. If you have sufficiently powerful hosts (exceeding the aggregate needs of hypervisor and virtual machines), then you can have SCVMM or library server co-located on the host, provided you account for the resource constraints of those servers as well. For instance, if you want to install SCVMM on Hyper-V host machine, then add the host’s requirements, virtual machine requirements, and SCVMM requirements, and then ensure that the machine has enough capacity. All of the following additional considerations assume that you have met this basic requirement.

For SCVMM to be installed on a Hyper-V host, it is highly recommended that the disk used for storing Hyper-V hosted virtual machines is different from the disk used for library. SCVMM server, in this case, will be running in the primary OS in Hyper-V. So, when the primary OS is loaded, all Guest OS (VMs deployed in Hyper-V) will have performance impact. To reduce this impact, configure the host reserves for that machine by adding the Hyper-V machine’s host reserves to the SCVMM machine requirements mentioned earlier. Host reserves can be configured using SCVMM administration console.

For a Hyper-V host to be used as a library server as well, you must have multiple disks in the machine. Separate disks must be used for the host’s virtual machines and for the library storage.

6. Networking: Hyper-V host should have line-of-sight visibility to TFS, SCVMM, and other library servers.

Hosts should be connected to SCVMM and library servers through a gigabit network.

Hyper-V hosts should ideally be on a network from where windows updates can be automatically applied. If this is not feasible, you should plan on keeping track of Windows and SCVMM updates, and apply them manually as and when they become available.

7. Domain: Hyper-V host should be joined to a domain that has 2-way trust with the domain of SCVMM server.

Additional tools and resources

1. Topologies: You may have complex networking topology requirements that restrict the networks in which TFS, SCVMM, Hyper-V hosts, and virtual machines running the application-under-test can be located. Or, you may want to configure network load balancing on your TFS. Use the following three topologies as examples of what you can setup.

- Topology #1 – Topology with multiple AT, Load Balancer and Test network with firewall settings controlling the test traffic in and out into the Corp network.

- Topology #2 – Topology with multiple ATs and DTs without load balancers and Test network with SAN based library and host.

- Topology #3 – Topology with TMG, Windows NLB and with Test apps having DB tier outside of LE.

- Topology #4 – Topology with multiple ATs and DTs, load balancers and Environments joined to a different domain.

2. Simple Capacity planner: See attachment.

Setting up various topologies to test with Visual Studio Lab Management – Part 3

Hariveer Singh — Fri, 07 May 2010 07:46:00 GMT

In this Part3 of this topology blog series, we will talk about a topology that has TMG proxy and with application tiers being load balanced with Windows NLB. We will also touch upon testing with Lab Environments that has one of their tiers (DB tier for this discussion) outside of the Lab Environment.

Take a look at Part1 and Part2 following the links.

Here is the recap of acronyms that we have been using in this blog series

Corp network – Would refer to the corp. network where TFS is hosted. A Corp network would have one or more ATs, DTs, Load balancers, Proxy, VMM server. Clients are typically connected to this network while at work.

Test network – Would refer to the network where the testing of the apps would happen. Test controller, Build controller, VMM server, VMM Library VMM hosts are present in this network. Please note that VMM server can either be in Corp network on in Test network depending on your choice.

Corp Domain – the domain controller in corp. network

Private Lab Domain – the domain controller in Private Test network.

AT – Application Tier

DT – Data Tier

VMM – System Centre Virtual Machine Manager

TC – Test controller

BC – Build Controller

BSH – Build Service Host

And few more that we would be using in this discussion…

TMG – Microsoft Forefront Threat Management Gateway

ALM – Application Lifecycle Management

LE – Lab Environment

LS – A Lab System within Lab Environment

VIP – Virtual IP or the Cluster IP in Windows NLB

Topology #3 – Topology with TMG, Windows NLB and with Test apps having DB tier outside of LE

This topology has following components in Corp network

Two Application tiers. Both the AT machines are configured with Windows load balancing. Both the App tiers have been configured to run with same domain service account.
A TMG proxy that controls the traffic flowing into TFS website.
A single data tier with default SQL instance

Following are the components in Test network

VMM server, Distributed Library shares, Host machines.
Test and Workflow controllers
All the machines have Windows firewall setting that controls the test traffic flow in and out of Corp network.
Test app deployed with one of the tier (DB tier) being outside of the Lab Environment

We have already seen how to configure multiple application tiers in both Part1 and Part2 and have specifically seen how to configure application tiers with same AT service account in Part1. The Windows firewall settings for controlling test traffic in and out of Corp network have also been discussed earlier in Part1.

So for our current discussion we will only talk about specific configuration requirements in TMG, Windows NLB and any AT configurations for enabling Visual Studio Lab Management 2010. We will also discuss about the implication of one of the App tier (DB tier in our case) being outside of Lab Environment with regard to ALM scenarios.

1) Windows NLB configurations

http://technet.microsoft.com/en-us/library/cc775749(WS.10).aspx talks in detail about how to create and manage load balancing clusters.

For our discussion, let’s assume we had the clustering mode as “Multicast” for this topology. You can also have the cluster mode as “Unicast” in your setup and that does not impact the behaviour of Visual Studio Lab Management 2010.

In our case, the configuration looks as below once the AT machines have been added as part of the NLB cluster.

Cluster IP – 192.168.1.10
AT1 dedicated IP – 192.168.1.2
AT2 dedicated IP – 192.168.1.1

2) TMG rules configurations

http://technet.microsoft.com/en-us/library/cc441445.aspx talks in detail about Forefront TMG deployment.

After Installing the enterprise, Please open the forefront TMG wizard

Configure network, system and deployment options in sequence
While configuring network settings, choose "Back Firewall"
Please provide all the appropriate data for the rest

After successful configuration add the firewall policy rule for enabling traffic to application tier:

Right click on "Firewall Policy" and create a "New" -> "Web Site Publishing Rule" for TFS AT Service.
Action -> Allow
From -> External, Perimeter
To ->
- Under Published Site : 192.168.1.10 (Appropriate VIP - Cluster IP of the windows NLB)
- Under Computer Name or IP Address : 192.168.1.10 (Appropriate VIP - Cluster IP of the windows NLB)
Traffic -> HTTP
Public Name ->
- Requests for the following Web sites
- Add the FQDN of the TMG machine external name
Paths ->
- Add Internal path as /*
- Select External path as "<same as internal path>"
Authentication Delegation -> No Delegation, but client may authenticate directly
Link Translation - >Do not check the box
Schedule -> Always
Users -> All Users
Bridging ->
- Web server
- Choose Redirect requests to HTTP port : 8080 <port on which AT Service is listening on or bound to>
Listener ->
- Networks -> External, Internal, perimeter checked
- Connections -> Enable HTTP connections on port : 80
- Authentication ->
  - No Authentication
  - Under Advanced -> Check "Allow client authentication over HTTP"
- Apply the properties
Apply the properties

Right click on "Firewall Policy" and create a "New" -> "Web Site Publishing Rule" for "Outbound ports".

The firewall rules for our topology looks as below once configured:

General properties

Listening on both External and Perimeter networks

Redirecting both HTTP and HTTPS connections to HTTP endpoint of application tier

Certificates for listening exposed HTTPS endpoint of TFS website in proxy

Exposed public name

Post this configuration, all the connections made to the Public name listened by the TMG proxy will be forwarded to the Cluster IP (192.168.1.10). The request will be load balanced and will be handled by one of the ATs which is part of this cluster.

3) URL settings and IIS bindings in Application tiers

IIS Bindings

Since in our case the ATs are not directly exposed outside of corp network, both the ATs will have the TFS website bound to http. There is explicit binding to its Cluster IP, Dedicated IP and Loop back in this case.

TFS URLs

The notification URL will be set the public name that is being listened by TMG. Launch TFS Admin Console –> Application Tier –> Change URL

The server URL will remain as loopback IP.

Lab URL

Given that Lab URL will be consumed only by Controller which is within the Corp network, we will change the default value of Lab URL to point to the HTTP endpoint of the local corpnet URL listened by TMG. By default the LAB URL will be same as notification URL, which in our case will be the publicly exposed name listened by TMG.

Controller configuration

The steps to configure Controllers are same as described in Part1 and Part2. Mention the local corpnet URL listened by TMG (same as what we configured for Lab URL) while providing the TFS URL during configuration.

4) ALM scenarios when one of the tier is outside the Lab Environment

Your Lab Environment may not always contain all the tiers within itself. There could be situations when one of the tier has to be outside of LE. Some of the reasons why a DB tier can be outside of the environment are

DB might be too big to host in a VM
DB performance within a VM could be unacceptable
DB might be shared among multiple apps – either read or read/write

When such an environment is used for testing, we will have to be mindful of few aspects that will impact the overall Lab Management 2010 ALM scenarios.

Environment snapshots

When one of the tier is not part of the LE, your manual testing scenarios or your build deploy test scenarios involving restoring snapshot to the clean state in the LE will only being the Lab systems within the LE to clean state. The tier which is outside of the LE will not be in consistent with rest of the tiers which may not be the required state for your testing to progress.

Facts to be mindful while testing manually

If there are DB schema changes in new builds that differs from your earlier state, users will have to take care to ensure DB schema is in compatible with rest of the app tiers.
If there is test data in DB that requires cleanup before next iteration of testing in the same setup, users will have to ensure the required cleanup is done.
If there are multiple testers working in different LE are sharing the same DB machine outside, it is important to have each of them work in separate database.
Testers can however share the same DB if they would only read from it and not write.

In summary, Visual Studio Lab Management 2010 has no knowledge of external dependencies of a LE and the user has to ensure that overall state of LE and its dependencies is maintained.

Customizing workflow to clean the external tier

To get the outside tier in a consistent state, you can customize your workflow template to clean up the tier outside during restore checkpoint.

Below is snip of how a customized workflow looks for our scenario where the DB tier is outside:

Add a invoke process activity which would invoke a remote script in DB machine that does the required cleaning

The below invoke process will be executed from build controller. Ensure that the credentials provided have enough privileges to do the cleanup in the data tier.

Network isolation and a LE tier outside

Cloning of a domain joined isolated application requires an AD inside the environment. Since AD VM is NOT connected to the external network in isolated environments, you can’t have any trust relationship between corp domain and the AD inside LE. For this reason, network isolation would not work for domain joined application if some pieces of that app, such as, DB were outside the LE.

Creating a bug when test fails in E2E

Hariveer Singh — Sun, 02 May 2010 16:39:57 GMT

Note: Cross posted from Nothing geeky....
Permalink

In one of the earlier post, we saw how to customize the E2E workflow to automatically create a bug on hitting a test failure. This post enhances the scenario further by taking a snapshot of the environment after the test run and attaching a link to the snapshot to the newly created bug.

Attached is the customized xaml that you can download and use directly, after checking-in the XAML to your source control and creating a new build definition based on that.

Let me go through the additional things I have done on top of what is explained in the previous post :

1. Drag and drop the activity "SnapshotLabEnvironment" from "TeamFouundation Lab Management activities" section in addition to the "OpenWorkItem" activity.

2. Define two new string variables in the scope of the "Sequence" and name them "LocalForwardLinkID" and "LocalsnapshotID".

3. Let's take a look at the "SnapshotLabEnrionment" activity .

This activity takes the "LabEnvironmentUri" and "SnapshotName" as input parameters and snapshots the given environment and returns the ID of the newly taken snapshot. In addition it has an output parameter called SnapshotChainID.

For "LabEnvironmentUri" input parameter, specify the variable LabEnvironmentUri ( the value for which would have been already set in the workflow).

Specify some value for "SnapshotName" input parameter. The snapshot I have given is "TestRunFailureSnapshot" + DateTime.Now.Ticks.ToString. The date time is appeneded to ensure uniqueness of snapshot name.

Assign the return value and the out parameter value of the snapshotLabEnvironment activity to LocalSnapshotID and LocalForwardLinkID respectively.

4. Next step is to pass on the snapshot detail to the newly created bug. As described in this post, it is possible to create Environment /Snapshots links if we know their IDs.

So let's compose a url for the newly taken snapshot and write that url in the bug description and we are done :)

Specify the below value for the "Comment" parameter of the "OpenWorkItem" activity.

String.Format("Snapshot of the environment when the test run happened is : <a href=""lvr://ConnectToFwdLink/?CollectionUri={0}&ForwardLink={1}"">here</a>", LabWorkflowParameters.EnvironmentDetails.TfsUrl, LocalForwardLinkID)

The above string is essentially the url for the newly taken snapshot composed using its ID . It is surrounded by a HREF tag to make it appear as a hyperlink in the bug.

5. Run the build and the new bug will be created when the test run fails. The new bug will look something like below.

6. Clicking on the "here" hyperlink from the history section in the bug will pop up the below dialog where can you chose to revert to the snapshot and debug your failure.

Cheers !

Lab Build agents – How it works

Hariveer Singh — Sun, 02 May 2010 16:39:32 GMT

Note: Cross posted from Nothing geeky....
Permalink

The Lab management end-to-end workflow works leverages the Team Foundation Build Agent/Build Controllers to do the deployment.

Given that build agent is primarily targeted for compiling sources, a getting-started user will get a bunch of questions :

a) How does the build agent inside a lab environment work ?

b) Can I use the build agent inside the lab environment for both compiling sources and deploying my application ?

c) How are the build agents selected for compiling sources ?

Let me try to answer the above questions. And before that, take a look at our Getting started with Lab Management series and Lab management videos

How does the build agent inside a lab environment work ?

The build agent inside a lab environment also does the regular functionality of executing the tasks given by build controller. In the case of an end-to-end (E2E) workflow ( which is nothing but a build definition), the task done by the agent will be deployment ( any script that user specifies : WIX, MSI, batch file, ps …) instead of compiling sources.

If you have lab service account set for your project collection, then the build agent will use that identity while talking to TFS.

Example: If you have your build agent running as domain\user account in your VM and set your lab service account as domain\svcaccount, then any out going call made by the build agent to the TFS will go with this identity. As the name implies, lab service account will be a service account with less privileges and hence this account will not be granted permissions on source control by default.

Can I use the build agent inside the lab environment for both compiling sources and deploying ?

The recommended way is to have a separate build agent machine for compiling sources.

The reasons being :

Lab build agents (== build agents inside a lab environment) communicate with TFS using the lab service account identity which doesn’t have permissions on source control ( which is required for building sources). So this will not work out of box. Few manual steps has to be done in order to achieve this.
Lab machines that has to be in a clean state for deployment and might not have all the targets needed for compiling sources.

Example: To build a share point app and build a wsp package, the sharepoint target binaries are required on the build machine and it is not possible to have that in the lab environment ( since the VMs need to be clean before deployment).

How is the build agent selected for compiling sources ?

For running the E2E workflow, you will be creating a build definition for compiling sources. The default "Agent selection criteria" for this build definition will be "Agent which has any name and which doesn’t have tags ". The default " Tags is empty" criteria is to ensure that lab build agents are not picked up for compiling sources ( lab build agent always carries few custom tags that are pushed by lab and will not satisfy this criteria).

If you have added tags to your non-lab build agents and just go with the default "Agent settings" options while creating the build definition, the tagged build agents will not be picked up for compilation and you might get an error which says "The build controller xxx does not contain an enabled build agent with name * and no tags".

To workaround the issue, chose the tags explicitly while chose the agent for compiling sources (like below) or have separate build controllers - one for managing compilation agents and another for managing lab build agents.

If you chose any of the lab build agents explicitly for compiling sources, then you will get an error saying "No matching items found in S/ in your workspace, or you do not have permissions to access them". This happens because the lab build agents will not have source control permission by default.

You might get the above error, when "MatchAtleast" is chosen instead of "MatchExactly" in which case the lab build agents might also get picked up.

How can I compile the sources using build agents inside the lab environment:

Though the general recommendation is to not use the build agents inside the lab environment for compiling sources, you might have a scenario to do so. In that case you need to do the below steps to acheive this :

Grant the lab service account "Read" permissions on the source control. By default when the a lab service account is set, it is denied source control permissions (to be "secure by default"). But, if you want your lab machines to compile sources then, the lab service account need to get the sources and hence it needs read permissions. This post explains how to give read permissions using "tf permisisons" command.
While creating the compilation build definition, make sure that you either explictly chose the specific lab build agent or chose a tag or set some name filter so that the lab machines get chosen ( the reason being, by default lab machines will be excluded from the selection as mention above).

Hope this helps!

Setting up various topologies to test with Visual Studio Lab Management – Part 2

Hariveer Singh — Fri, 23 Apr 2010 11:39:00 GMT

In Part1 of this blog series, we talked about a topology which had a load balancer and multiple application tiers, and also had the test network which has explicit firewall settings to control the test traffic flowing in and out of test network.

In this Part2, we will pick a topology that does not have load balancer but with multiple application tiers and data tiers and look at configuration aspects that are specific to enabling Visual Studio Lab Management. We will also touch upon supported SAN configurations in test network.

Before we start with these topics, I would like to list down the acronyms that we would be using in this article. These are mentioned already in Part1, but I am listing them again here.

Corp network – Would refer to the corp. network where TFS is hosted. A Corp network would have one or more ATs, DTs, Load balancers, Proxy, VMM server. Clients are typically connected to this network while at work.
Test network – Would refer to the network where the testing of the apps would happen. Test controller, Build controller, VMM server, VMM Library VMM hosts are present in this network. Please note that VMM server can either be in Corp network on in Test network depending on your choice.
Corp Domain – the domain controller in corp. network
Private Lab Domain – the domain controller in Private Test network.
AT – Application Tier
DT – Data Tier
VMM – System Centre Virtual Machine Manager
TC – Test controller
BC – Build Controller
BSH – Build Service Host

Topology #2 – Topology with multiple ATs and DTs without load balancers and Test network with SAN based library and host.

The topology that we would pick for discussion today is as follows:

This topology has following components in Corp network

Two Application tiers, out of which one of them is exposed to outside of Corp network and the other is servicing requests completely within Corp network. Each application tier in this case will be configured to run with Network service account.
A AT source control proxy
Two data tier named instances one for config DB and the other for Collection DBs

And the following components in Test network

VMM server, Library and Host; with VMM library and host having their drives mapped to SAN disk space.
Test and Workflow controllers

Please note that the Test network in this case is just a different LAN segment, but the components in Test Network are all joined to Corp domain. I would like to again reiterate the fact that for Visual Studio Lab Management 2010 release, we require all of the below components to be in same trusted domain; TFS, Test and Workflow controllers, VMM server, library & Host.

Let’s look at the configurations of each of them, specifically the ones required to enable Visual Studio Lab Management. I am not going to cover the firewall setting aspects as they are same as what we covered in Part1.

1) Setting up Application tiers

Installing & Configuring AT exposed to non Corp network (AT1)

a) Installation and Collection creation

Follow the Team Foundation 2010 Setup instructions to install the primary application tier.

While configuring the TFS ensure that the AT service account is selected to run as Network service account, as per our need for this example; point to appropriate named SQL DB instance when pointed for, in our example topology lets say it is DT1\CONFIGDB.

While creating new collections, provided the named SQL DB instance, in our topology say it is DT2\CollectionDB

b) Setting appropriate IIS bindings

Bind your TFS website with HTTP, port (8080, by default for TFS) and appropriate IP bindings. Given that this Application tier is also exposed to non Corp network add a HTTPS binding with appropriate SSL certificate. Example of such a bindings viewed from inetmgr in my server looks as below

You can take a look at http://blogs.msdn.com/ablock/archive/2009/08/24/exposing-tfs-2010-beta-2-to-the-internet.aspx which talks about ways to expose TFS to internet.

c) Setting appropriate Notification and Server URLs

Given that there are clients who would be accessing the server from outside of Corp network, set the Notification URL to be HTTPS URL. Click on “Change URLs” in TFS Admin console at Application Tier level and modify the notification URL.

Retain the Server URL as it is as localhost.

d) Setting appropriate Lab URL

Click on Application Tier –> Lab Management –> Re configure Lab Management –> Advanced tab and check the Lab URL. The Lab URL will be same as Notification URL, in our example we should see https://TFS.mycorp.com:8443 which was set in step above. Lab URL is used by build agent in Lab environment while connecting to the TFS. Hence edit the Lab URL to http://tfsfqdn.mycorp.com:8080/tfs.

If you wish to configure build agent to communicate to TFS via HTTPS, then you should install appropriate client SSL certificate before you prepare the golden templates. In that case, you could retain the HTTPS url as your Lab URL.

e) Collection level settings for Lab Management

Take a look at Visual Studio 2010 setup instructions for TFS and Lab Management and configure the Lab management host group, library share and Lab service account at collection level. The getting started video of Lab Management should help to get started with Lab Management configurations, http://blogs.msdn.com/lab_management/archive/2010/02/11/visual-studio-lab-management-videos.aspx.

Launch Admin console –> Click Team Project Collections under Application Tier –> Click on Collection –> Click on Lab Management Tab –> Click on Configure Library Shares and configure the Library shares.

Click on Hostgroups Tab and configure the Hostgroup for Lab Management.

Click on Service account Tab and configure Lab service account

Installing & Configuring AT servicing requests only with Corp network (AT2)

a) Installing AT only

Follow the TFS 2010 setup instructions to install and configure “AT only” configuration. In our example we want all the application tiers to be running as Network service account. Launch TFS Admin Console and check if the AT service account is configured as Network Service. If not change it to Network Service by clicking on Application Tier –> Change Account.

b) Setting appropriate IIS bindings

Given that this AT will be servicing requests only within Corp Network set the TFS website bindings to HTTP, port 8080 and appropriate IP if required.

c) Secondary AT service account provisioning for Lab Management

Visual Studio Lab Management does account provisioning of TFS service account in VMM server and Host for it to function well. This is done as part of configuring VMM server at AT level and while configuring Hostgroup and Library share at collection level.

In our example, since each AT is running as Network service account, both the machine accounts will have to be provisioned. The primary AT account will already be provisioned when you complete the Lab configuration and Host group, Library share configuration as explained earlier.

In order to provision the secondary AT account in VMM server, from secondary AT launch TFS Admin console –> click Lab Management under Application Tier –> Click Re-configure Lab management –> In Virtual Machine Manager tab click on the “test” link. As part of test verification it will automatically provision the service account in VMM server.

In order to provision the secondary AT account in VMM hosts, open Lab Management settings as explained earlier while configuring new hostgroup for primary AT. Click on individual hostgroup and click verify.

Installing & Configuring AT Source control proxy

Follow the Visual Studio 2010 TFS AT proxy installation steps for installing AT proxy. There is no Lab Management specific configuration required to be done in proxy.

2) Setting up Controllers

Take a look at the Visual Studio 2010 setup instructions for Test controller setup and TFS 2010 setup instructions for Build controller setup. The getting started video of Lab Management should help http://blogs.msdn.com/lab_management/archive/2010/02/11/visual-studio-lab-management-videos.aspx.

For this topology, while configuring the controller you have the option to either point to AT1 HTTP endpoint or AT2 HTTP endpoint. In case you choose to use AT HTTPS endpoint while configuring the controllers then you need to have appropriate client certificates installed in your controllers. However, for performance reasons it is not recommended to use HTTPS end point if your TFS and Controllers are within the Corp network.

Build controller

Test Controller

3) Setting up VMM Server, VMM Library and VMM Host with SAN storage

Take a look at the TFS 2010 setup instructions for configuring Lab Management and SCVMM setup instructions. The getting started video of Lab Management should help http://blogs.msdn.com/lab_management/archive/2010/02/11/visual-studio-lab-management-videos.aspx.

With regard to SAN support, Visual Studio Lab Management 2010 does not support or leverage clustering. This would mean you cannot have test setup with VMM host clustering or create VMs that are cluster aware.

However, if you decide to have your VMM library and VMM Host disk space in a SAN drive for space and reliability needs, you will have to have separate LUNs mapped for VMM and the Host disk. Even if the LUNs are managed by same controller, given that Visual Studio Lab Management 2010 does not leverage any of SAN functionalities, the underlying BITS copy during a virtual machine deployment will happen all the way from Library to Host via your LAN network.

4) Clients

Clients in Corp network can connect either to either AT1 HTTP endpoint or AT2 HTTP endpoint.

Clients in Internet will need to have the client certificate to connect to the AT1 HTTPS endpoint that the application tier is bound to. If you are in un trusted domain but accessing the exposed TFS website, you will have to authenticate yourselves while connecting to the TFS.

The other details with regarding to lab operations that could be performed from client outside Corp network remains same as we discussed in Part1.

5) Golden Templates

The Golden template preparation steps are same as what was discussed in Part1.

Setting up agents/controllers for lab

Darshan Desai [MSFT] — Wed, 21 Apr 2010 05:57:04 GMT

In order to deploy your build and run your tests on a virtual environment, you need to enable the workflow and testing capabilities of the environment. To successfully configure these capabilities, you need to understand a few concepts and how different pieces integrate, viz. test agent, test controller, build agent, build controller, lab agent. The purpose of this post is to:

Explain these concepts and show you how they fit together
Explain the why, what, and how – for both these capabilities

The big picture

Let us start with the final view of an environment, configured to run tests and workflows. You can find the status of the different capabilities (and errors if any) from the Environments tab in Lab Center of Microsoft Test Manager. The following screen shot shows an environment ready to run tests and deployment workflows. You can enable these capabilities when you create the environment.

In order to get these capabilities ready, you need to do some (one-time) steps and setup/ configure the right pieces. Here is a picture that explains how the capabilities work and the different blocks involved.

Here is another view of what agents are needed on the virtual machines for each environment capability.

Environment Capability	Lab Agent Required?	Test Agent Required?	Build Agent Required?
Testing	√	√	X
Deployment workflow	√	X	√
Network Isolation	√	X	X

Individual blocks

Now, let us deep-dive into the answers for why the capability is needed, what all pieces need to be configured, and how to configure them. Refer to the diagram above to understand how the components interact with one another.

0. Pre-requisites

- We highly recommend you to set up a service account for lab management. By doing this, you don’t have to take care of permissions for the agents/controllers individually. Find out more about service account here. The setup guide explains how to setup lab service account here.

Note: The rest of this article assumes you have set up the lab service account.

1. Testing capability

Why?

In order to run manual or automated tests on an environment, you need to enable the testing capability. For manual tests, the testing capability lets you collect rich logs (ex: Intellitrace, event logs) from the various roles/machines that are part of the virtual environment. You can also take snapshot of the environment from the test runner and attach a link to it with the bug. You can run automated tests on environments where testing capability is enabled and ready.

What?

- To get the testing capability working, you need to install/configure the lab agent and test agent on each of the virtual machine(s) that are part of the environment. If you have VM templates stored in your library, install these agents on the templates.

- You also need one (or more) test controller(s) setup and registered with the team project collection you are connected to. The test controller is outside the virtual environment. To understand where to setup the test controller, you can review the ‘Choose a deployment topology’ section here.

How?

- Lab agent, test agent and test controller are part of the Visual Studio Agents 2010 package. You can download and install Visual Studio Agents here. You can find documentation on how to configure the agents here.

- We recommend you use VM prep tool to automatically install the lab agent and test agent on the machines in the environment or on the templates from which the VMs are created. Review the usage and download VM prep tool from here.

- Once you have your environment set up with testing capability, review the documentation to learn how to run manual tests and automated tests on the environment.

2. Workflow capability

Why?

In order to deploy your build and run automated tests on your virtual environment, you need to enable the workflow capability. In other words, you can run a build-deploy-test workflow on an environment where the workflow capability is ready.

What?

- We use the build agent/build controller framework to run the deployment workflows on the environments. While it is the same build agent/controller used to create your daily builds, it is important to note that the same components have been re-used to deploy your builds on the environment.

- To get the workflow capability working, you need to install/configure the lab agent and build agent on each of the virtual machine(s) that are part of the environment. If you have VM templates stored in your library, install these agents on the templates.

Note: The build agent should be configured to run either as “NT Authority\System” (LocalSystem) or under an account with local administrator privileges. This is needed to run deployment workflows.

- You also need one (or more) build controller(s) setup and registered with the team project collection you are connected to. The build controller is outside the virtual environment. To understand where to setup the build controller, you can review the ‘Choose a deployment topology’ section here.

How?

- Build controller and build agent are part of Team Foundation Server installer available here. Lab agent is part of Visual Studio Agents package available here. You can find documentation on how to configure the agents here.

- We recommend you use VM prep tool to automatically install the lab agent and build agent on the machines in the environment or on the templates from which the VMs are created. Review the usage and download VM prep tool from here.

- Once you have your environment set up with workflow capability, review the documentation to learn how to deploy your build on the environment and run automated tests after deployment.

Summary

By setting up the agent/controllers as described above, you should quickly be able to get the environments ready to run tests and deployment workflows. If you face any trouble with these capabilities, you can check out the troubleshooting guide here. If you have any comments or feedback, please let us know.

Visual Studio Lab Management team blog

Migrating to the Visual Studio ALM blog: http://blogs.msdn.com/b/visualstudioalm/

Lab Management walkthrough using Visual Studio 11 Developer Preview Virtual Machine

Lab Management in Visual Studio 11 Developer Preview

How to run the same test in different Lab Environments?

Enter/Vote for your favorite feature suggestions - UserVoice site is here!

ALM Rangers have published Visual Studio Lab Management guidance

New QFE for Visual Studio 2010 testing tools

Configuration matrix testing using Visual Studio Lab Management

Support for Windows Server 2008 R2 SP1 hosts and SCVMM 2008 R2 SP1

Running Build-Deploy-Test workflow on physical environments

Pre-requisites

Steps to setup and configure the workflow

Limitations

Enabling Host based connection for virtual environments

Does Lab Management support non-Hyper-V platforms?

Updated lab management videos

VM Prep Tool for Visual Studio Lab Management 2010 GDR is now available!

Lab Management General Distribution Release is now available

General Availability of Visual Studio Lab Management announced

Visual Studio Lab Management 2010 – Host group and Library Share management

1.0 Host group management

2.0 Library Share management

3.0 Host management

4.0 Best Practices

Lab Management (pre-release) 2010 Walkthrough VHD

Table of contents

Overview

Setup Steps

Pre-requisites

Import the virtual machine

Configuring virtual network adapters

Launch the Virtual Machine

Virtual Machine configuration

Hyper-V host configuration

Lab Management configuration

Scenarios

Scenario 1: Provision environments quickly

Scenario 2: Automate the build-deploy-test cycle

Scenario 3: File rich bugs with environment snapshots

Activation

Activation steps

Advanced Scenarios (optional)

Scenario 4: Build-Deploy-Test workflow on a multi-machine environment

Scenario 5: Network Isolation

Appendix

Setting up various topologies to test with Visual Studio Lab Management – Part 4

Topology #4 – Topology with multiple ATs and DTs, load balancers and Environments joined to a different domain

Planning considerations for setting up a lab managed by Visual Studio Lab Management 2010

Setting up various topologies to test with Visual Studio Lab Management – Part 3

Topology #3 – Topology with TMG, Windows NLB and with Test apps having DB tier outside of LE

1) Windows NLB configurations

2) TMG rules configurations

3) URL settings and IIS bindings in Application tiers

4) ALM scenarios when one of the tier is outside the Lab Environment

Creating a bug when test fails in E2E

Lab Build agents – How it works

Setting up various topologies to test with Visual Studio Lab Management – Part 2

Topology #2 – Topology with multiple ATs and DTs without load balancers and Test network with SAN based library and host.

Setting up agents/controllers for lab

The big picture

Individual blocks

0. Pre-requisites

1. Testing capability

2. Workflow capability

Summary