Visual Studio Lab Management team blog

TFS 2010 Best Practice Analyser Beta2 is now available

2009-12-02T17:38:00Z

Team Foundation Server Best Practice Analyser (BPA) a diagnostic tool (released as part of TFS 2010 Power Tools) is now available for public download; see Brian Harry’s post on the announcement. You can download it from the MSDN Visual Studio Gallery.

Lab Management checks are now also integrated with the BPA. So when you do a BPA scan against your TFS 2010 deployment, various Lab Management resources are verified if they are configured according to the recommended best practices.

Gathers Lab Management configuration information from the TFS
Performs specific tests on the System Center Virtual Machine Manager (SCVMM) Server configured for Lab Management
Performs various checks on the Hyper-V Hosts, Library Servers and Test Controllers added to a Project collection
Analyses the collected information according to specific rules and reports the findings as information, warning, or error messages
Provides links to documentation articles to resolve warning and error messages

For discussion on Power tools, visit the Team Foundation Server – Power Tools & Add-ons forum. If you find a bug or would like to make a suggestion for future versions, please report on Connect site.

The Lab Management team

Time for feedback about Beta 2

2009-12-02T12:46:53Z

It has been almost 6 weeks since Visual Studio 2010 Beta 2 was released. Some of you have already upgraded your live TFS and started using test and lab management with your teams and gave us specific feedback, which we are taking seriously and incorporating in the product. Some of you were more quiet…

We would like to get your current status and feedback about Beta 2, and specifically about Lab Management. We’ve create a short survey and it will be really helpful if you can take 5-10 minutes to respond to it. It is OK to answer the survey if you are still in the stage of setting up lab and have not completed it yet.

The survey is available here: http://www.surveymonkey.com/s/68N2FCD

Thanks in advance,

The Lab Management team

Network isolation on Windows Server 2008 R2 hosts

2009-11-26T17:16:00Z

Network isolation does not work on Windows Server 2008 R2 hosts if you are using Beta2 version of Visual Studio Team Lab Management. When you create an environment with network isolation on a 2008 R2 host and start it, you will get the following error:

Network isolation timed out. Last known status: Acquiring external IP for the Lab system from DHCP. Pause and start the environment to retry the operation. If the problem persists, shutdown and start the environment.

The root cause of this is a MAC spoofing issue in SCVMM. SCVMM has a QFE to fix the problem (http://support.microsoft.com/kb/976244). The QFE needs to be applied on the VMM server. If you are using Beta2 of Team Lab Management, and if you apply the QFE, you will see a slight improvement in how network isolation works on Windows Server 2008 R2 hosts. For instance, you will be able to start a network isolated environment and get the network isolation capability to become 'ready'. However, when you restore that environment to a snapshot or do other complex stuff, network isolation will still not work.

To get network isolation to fully work on 2008 R2 hosts, you will will have to not only install the SCVMM QFE but wait for the RC version of Visual Studio Team Lab Management! Meanwhile, with Beta2 version, network isolation works just fine on Windows Server 2008 SP2 hosts.

Building VMs out of the downloadable Win2k8R2 vhds

2009-11-23T17:06:42Z

This posts walks you through how to create VMs from the Win2K8R2 vhds you can download from here. If you are an SCVMM / Hyper-V expert, you can skip this section.

Launch the downloaded exe

C:\vmimages>"Windows Server 2008 R2 Enterprise Evaluation (Full Edition).exe"

Extract the image to your MSSCVMMLibrary and make two copies (one for the TFS and another for the test machine)

c:\ProgramData\Virtual Machine Manager Library Files\VHDs>dir
 Volume in drive C has no label.
 Volume Serial Number is 2EA8-7235

 Directory of c:\ProgramData\Virtual Machine Manager Library Files\VHDs

11/21/2009  07:07 AM    <DIR>          .
11/21/2009  07:07 AM    <DIR>          ..
10/30/2008  12:39 PM           125,440 Blank Disk - Large.vhd
10/30/2008  12:39 PM            35,328 Blank Disk - Small.vhd
08/10/2009  07:11 AM     6,939,326,464 TestW2KR2.vhd
08/10/2009  07:11 AM     6,939,326,464 TFSW2K8R2.vhd

Go to the “Library” tab in the SCVMM admin console (bottom left), click on the library server and select refresh. This will bring the vhd’s you copied just now to the library immediately. (The library by default gets refreshed once an hour).

Go to the “Virtual Machines” tab (bottom left) in the SCVMM admin console and select “New virtual machine” (top right). Select the “TestW2K8R2.vhd”

Give the VM a name

Change RAM to 1GB, and Connect it to network

Select the right OS flavor

and “select start after deploying it to the host”.

Follow the same steps for the TFS VM also, but change the RAM to 2048MB and deploy it. Do not select the “start after deploying it to host” – as both will have the same names and will create collision.

These vhds are created by a process called “sysprep”, and when you start the VMs they go through the “specialization” process to create unique machine SIDs, plug-n-play detection, activation resets etc. Once the 1st VM is up, connect to the VM and logon. The web page from where you downloaded the VHDs has the password.

To logon to the machine, use the following credentials: 
Username: administrator, password: Pass@word1 (Administrator account)

Change the machine name, join it to a domain, enable remote desktop on it, activate windows, add a domain account as administrator on the box, download and install the latest patches and reboot.

Launch the TFS VM now, and go through the same motions described above.

Getting started with Lab Management (Part 4)

2009-11-23T17:04:08Z

In the last post, we created the “system under test” and ensured that the TCM server has information on how to run these tests in a test environment. This post explains how to get the tests run automatically as part of a scheduled build / deploy / test workflow.

Creating the deployment script

The first step is to create a deployment script that can deploy the build and tests from a build drop location to the virtual environment. Let us create a batch script file called “deploy.cmd”. The script below works on IIS7. IIS6 users would have to make changes to use iisvdir.vbs rather than the appcmd used below. Add the deploy.cmd to the calculator application and check it in.

set RemotePath=%1
set LocalPath=%SystemDrive%\Calculator

if not exist %RemotePath% (
    echo remote path %RemotePath% doesn't exist
    goto Error
)
if exist %LocalPath% (
    rmdir /s /q %LocalPath%
)

REM Copy files to the local machine
mkdir %LocalPath%
copy /y %RemotePath%\* %LocalPath%\.
xcopy /cseirhdzv %RemotePath%\_PublishedWebsites\Calc %LocalPath%
@echo Copied the build locally

REM Configure IIS and ASP.NET
%windir%\system32\inetsrv\appcmd add app /site.name:"Default Web Site" /path:/Calc /physicalpath:%LocalPath%
@echo added new IIS VDir
%windir%\system32\inetsrv\appcmd set app "Default Web Site/Calc" /applicationPool:"ASP.NET v4.0"
@echo set the app pool to run under ASP.NET v4.0

icacls %LocalPath% /grant "BUILTIN\IIS_IUSRS:(OI)(CI)(F)"
icacls %SystemRoot%\ServiceProfiles\NetworkService\AppData\Local\VSEQT /grant "BUILTIN\IIS_IUSRS:(OI)(CI)(F)"

:Success
echo Deploy succeeded
exit /b 0

:Error
echo Deploy failed
exit /b 1

Configure the build drop location:

Create drop directory where the output of build will go to, and provide permissions to accounts to write to the location.

C:\>type .\configdrop.cmd
@echo off
md drops
net share drops=c:\drops
icacls c:\drops /grant "NT AUTHORITY\Network Service:(OI)(CI)(F)"
@echo Granted permission to Network Service

:nextmachine
if "%2"=="" goto end
icacls c:\drops /grant "%1\%2$:(OI)(CI)(F)"
@echo Granted permission to %1\%2$
shift /2
goto nextmachine

:end
@echo all done

C:\>.\configdrop.cmd fareast varadab2tfs varadab2vm1
……

Create the build definition:

Back in Visual Studio, go to Team Explorer, and create a “new build definition”. This build definition will be used to compile the solution.

In the build defaults, configure the build drop location to use the drop location we created

In the Process tab, select the agent to use to do the compilation as the agent in the TFS machine. (This requirement has been removed post Beta 2). Set the solution to build and remove running the unit tests as part of the build experience.

Call the build definition “Calculator – Build” and save the build definition. This is used to build the solution.

Create the E2E workflow definition:

Now that we have a build definition which can be used to build the solution, we will wrap that in a end to end definition which will build the solution, deploy it to the VM, test it and report the results.

Create another build definition “Calculator – E2E” and after choosing the same set of entries, change the process tab to select “LabDefaultTemplate.xaml”

And click on the button associated with workflow settings.

Select the environment and the clean check point to revert to. The clean checkpoint helps avoid machine taint issues when running your tests, and thus is highly recommended.

Use the “Calculator – Build” definition that we created before. This definition is used to build the solution.

On the deploy tab, we are telling the system, how to bootstrap the environment with the latest bits. We are using the Deploy.cmd we created earlier to deploy the bits to the VM.

Also note that I am taking a snapshot post the deployment. There are many scenarios where a bug is reported on a particular build. It is easy for a developer to restore to that build, and start debugging. A link to the snapshot file gets stored in the path provided. (\\varadab2tfs\drops – in my case)

We select the tests, the plan, configuration and settings and finish.

Queue the workflow:

Select the E2E template and “Queue New Build…”

And you should see that as part of the queued build, the latest solution is built (by the Calculator – Build definition), environment is restored to the clean snapshot, bits are deployed to the environment using our deployment script, a snapshot is taken post the deployment, our unit tests are run and the results are available for you to analyze in the “Microsoft Test and Lab Manager”.

This concludes the series of getting started with lab. Let us know how your experiments with lab go.

Getting started with Lab Management (Part 3)

2009-11-20T02:03:00Z

Configuring the “system under test” in VS

The system under test for the purpose of this walkthrough is a simple calculator web service with its unit tests.

Start by creating a new team project in VS. Connect to the TFS server and create a team project (Labwalkthru). The solution is attached to the blog post.

Calculator app:

  1: using System.Web.Services;
  2: 
  3: [WebService(Namespace = "http://tempuri.org/")]
  4: [WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]
  5: public class CalculatorService : System.Web.Services.WebService
  6: {
  7:     public CalculatorService()
  8:     {
  9:     }
 10: 
 11:     [WebMethod]
 12:     public long Add(long lNum1, long lNum2)
 13:     {
 14:         return lNum1 + lNum2;
 15:     }
 16: 
 17:     [WebMethod]
 18:     public long Subtract(long lNum1, long lNum2)
 19:     {
 20:         return lNum1 - lNum2;
 21:     }
 22: 
 23:     [WebMethod]
 24:     public long Multiply(long lNum1, long lNum2)
 25:     {
 26:         return lNum1 * lNum2;
 27:     }
 28: 
 29:     [WebMethod]
 30:     public long Divide(long lNum1, long lNum2)
 31:     {
 32:         return lNum1 / lNum2;
 33:     }
 34: }

Test code:

  1: using Microsoft.VisualStudio.TestTools.UnitTesting;
  2: using Microsoft.VisualStudio.TestTools.UnitTesting.Web;
  3: 
  4: namespace CalcTest
  5: {
  6:     /// <summary>
  7:     ///This is a test class for CalculatorServiceTest and is intended
  8:     ///to contain all CalculatorServiceTest Unit Tests
  9:     ///</summary>
 10:     [TestClass()]
 11:     public class CalculatorServiceTest
 12:     {
 13:         private TestContext testContextInstance;
 14: 
 15:         /// <summary>
 16:         ///Gets or sets the test context which provides
 17:         ///information about and functionality for the current test run.
 18:         ///</summary>
 19:         public TestContext TestContext
 20:         {
 21:             get
 22:             {
 23:                 return testContextInstance;
 24:             }
 25:             set
 26:             {
 27:                 testContextInstance = value;
 28:             }
 29:         }
 30:         
 31:         /// <summary>
 32:         ///A test for Add
 33:         ///</summary>
 34:         [TestMethod()]
 35:         [HostType("ASP.NET")]
 36:         [UrlToTest("http://localhost/Calc")]
 37:         public void AddTest()
 38:         {
 39:             CalculatorService_Accessor target = new CalculatorService_Accessor(); 
 40:             long lNum1 = 1;
 41:             long lNum2 = 1;
 42:             long expected = 2;
 43:             long actual;
 44:             actual = target.Add(lNum1, lNum2);
 45:             Assert.AreEqual(expected, actual);
 46:         }
 47: 
 48:         /// <summary>
 49:         ///A test for Subtract
 50:         ///</summary>
 51:         [TestMethod()]
 52:         [HostType("ASP.NET")]
 53:         [UrlToTest("http://localhost/Calc/Default.aspx")]
 54:         public void SubtractTest()
 55:         {
 56:             CalculatorService_Accessor target = new CalculatorService_Accessor();
 57:             long lNum1 = 5;
 58:             long lNum2 = 2;
 59:             long expected = 3;
 60:             long actual;
 61:             actual = target.Subtract(lNum1, lNum2);
 62:             Assert.AreEqual(expected, actual);
 63:         }
 64: 
 65:         /// <summary>
 66:         ///A test for Multiply
 67:         ///</summary>
 68:         [TestMethod()]
 69:         [HostType("ASP.NET")]
 70:         [UrlToTest("http://localhost/Calc/Default.aspx")]
 71:         public void MultiplyTest()
 72:         {
 73:             CalculatorService_Accessor target = new CalculatorService_Accessor(); 
 74:             long lNum1 = 2;
 75:             long lNum2 = 5;
 76:             long expected = 10;
 77:             long actual;
 78:             actual = target.Multiply(lNum1, lNum2);
 79:             Assert.AreEqual(expected, actual);
 80:         }
 81: 
 82:         /// <summary>
 83:         ///A test for Divide
 84:         ///</summary>
 85:         [TestMethod()]
 86:         [HostType("ASP.NET")]
 87:         [UrlToTest("http://localhost/Calc/Default.aspx")]
 88:         public void DivideTest()
 89:         {
 90:             CalculatorService_Accessor target = new CalculatorService_Accessor();
 91:             long lNum1 = 10;
 92:             long lNum2 = 2;
 93:             long expected = 5;
 94:             long actual;
 95:             actual = target.Divide(lNum1, lNum2);
 96:             Assert.AreEqual(expected, actual);
 97:         }
 98:     }
 99: }
100:

When extracting the solution from the zip file, you can extract the attached zip file and from an elevated command prompt

C:\calc>AddCalctoIIS.cmd
APP object "Default Web Site/Calc" added
VDIR object "Default Web Site/Calc" added
added new IIS VDir
APP object "Default Web Site/Calc" changed
set the app pool to run under ASP.NET v4.0
processed file: C:\calc\Calc
Successfully processed 1 files; Failed processing 0 files
setup the right permissions

Add the solution to the Labwalkthru project in source control and build it. For running these tests in a remote lab environment, these tests to be part of the TCM in TFS. Import the test cases to TCM by using the tcm command.

C:\calc\calctest\bin\Debug>
tcm testcase /import /collection:http://varadab2tfs:8080/tfs/DefaultCollection /teamproject:Labwalkthru
/storage:CalcTest.dll
Modification   Title
-------------- -----------------------------------------------------------
Added          AddTest
Added          SubtractTest
Added          MultiplyTest
Added          DivideTest
Summary
--------------
Added          4
Updated        0
Removed        0
Total          4

Create the rest of the Test assets:

We should provide the BVT experience a test suite to run, so launch the “Microsoft Test and Lab Manager” and connect to the project.

Create a test plan by clicking on Add

Let us call it “BVT tests” and select the “Select plan”

In the tests add the tests that we just imported

Create a Lab Environment for running the tests:

In MTLM, move from test center to Lab center.

Create a new virtual environment

and in the machine tab, select import

and import the prepared VM stored earlier

Finish the import and click Add to Environment, edit the role to be Web Server

Add “Run test” and “Run workflow” capabilities

and click the “Finish” button. This will create a test environment which can be used as part of the “build / deploy & test workflow”. At this point, lab will deploy the store environment in the library share to a hostgroup. This will take a bit of time to complete.

After the environment is up and running, you should see that the workflow capability and test capability are all ready in the environment.

In our case, on the environment, we are running web tests as NetworkService (the test agent is configured by default to run as networkservice). To run tests in ASP.NET, the user has to be administrator on the machine. So connect to the lab machine,

logon to the VM and add Networkservice as member of the administrators group and then reboot the machine.

C:\>net localgroup administrators /add "NT AUTHORITY\Network Service"

Reboot the machine to allow for this to take effect.

When the tests run, you would want to restore the environment to a clean snapshot. Take the snapshot, by clicking on the “Take Snapshot” icon.

Let us call the Snapshot, “CleanCP”

Create test settings for the automated run:

Create a new test setting and set the test run to automated.

In the Roles tab, select the web server role (VM1) to be the role where tests are run. This is needed in case where your environment has multiple roles, you can pick the right role where the tests get run.

And finish.

In the next blog post, we will connect all the dots to execute the test runs as part of the dev workflow.

Getting started with Lab Management (Part 2)

2009-11-18T08:38:00Z

Configure the TFS VM:

In our setup, we will configure TFS server, the build controller, build agent to do the build process, test controller which will manage test execution and also as the dev box where we will write the code. This can be a VM in the same host if you can spare 2GB of RAM on the host.

SCVMM admin console
TFS
Build Controller
Test Controller
VS

Install SCVMM Admin Console:

Start the SCVMM install on the TFS server, and select the administrator console option. Select the default set of steps, and let it complete. The lab management service that will run on TFS needs the SDK installed by the admin console to communicate to the TFS server.

Install Team Foundation Server:

In my configuration, I am setting up TFS, the build controller, test controller and Visual Studio all in the same box (a 64bit Win28R2 VM with 2GB RAM).

If you are using a physical box, you need to burn DVDs from the ISO files of the 3 ISOs you downloaded (VS2010B2Agent1.iso, VS2010B2TFS1.iso, VS2010B2Ult.iso).

If you are using a VM as the TFS server, you can on the SCVMM host, configure the VM where the TFS & the rest are to be installed to have 3 DVD drives where the isos are mounted, to help ease the installation. (The VM should be shutdown before you can add DVD drives)

After launching TFS install from the DVD, select both TFS server and the build controller to install

On the configuration screen, select Basic

Let TFS install complete with the default selections.

Once the TFS configuration is complete, next step is to configure the build service. Launch the “Build Service Configuration Wizard” and associate it with the DefaultCollection created by the TFS install.

Use the default settings for the rest and go ahead with the configuration.

Install and configure Test Controller:

Launch the Team agents setup (the agents iso file – in your another DVD drive), and select “Install Visual Studio Team Test Controller 2010”.

Select defaults and let the install complete. Register the test controller against the project collection that was created.

Setup permissions for the lab clients to talk to TFS and test controller:

(Note: the below option is not a scalable approach. I am just using it to make it simple for the purpose of the walk through. The RC bits will have a better approach for handling security).

Test permissions

On the test controller machine,

C:\>net localgroup TeamTestAgentService /add fareast\varadab2vm1$

Build permissions:

Launch the TFS admin console, go to the default collection, in the “General” tab select “Administer Group Membership” and group “Project Collection Build Service Accounts”

And add the test VM to the group (note that you have to select “Computers” in the search scope for object type to find the VM name – by default, only Users and Groups are searched).

Configure Lab:

Launch the TFS Administration Console and start configuring Lab Management.

Click on Test

Provide the admin credential for the SCVMM host. This will ensure that TFS can ask SCVMM to do operations like “Create VM” and such. The Network location combo box will now be populated.

Select OK to finish configuration of lab in the Application Tier.

Configure Lab for Project Collection:

Continuing in the TFS admin console, select the lab management tab in the default collection.

Select Configure Library shares – this allows individual project collections to have their specific library shares and host groups. For our purposes, we just work with all the resources we have.

and “Verify”

Provide an administrator credential that works on all the hosts (1 in my case, but can be 2), and press OK. This configures lab for the project collection.

Install VS2010

Install VS2010 ultimate (another DVD drive) with the default configuration.

In the next blog post, we will create the system under test and start actually seeing lab in action.

Getting started with Lab Management (Part 1)

2009-11-18T08:35:00Z

Lab management is a new addition to the Visual Studio family with VS2010. The product uses virtualization to build and manage labs in the dev / test environment. The promise of the product is three fold.

Using virtualization, machine utilization and hardware costs of managing labs will be much better than building out and maintaining physical labs.
Increased productivity of the dev/test team – various surveys indicate that test members spend 30 – 50% of their time in setting up their test bed and getting it ready for testing. The product leverages the virtualization to vastly reduce the cost of this bootstrap. Leveraging the rich snapshot / restore models, it allows you to set up a pristine base environment (group of VMs) and then start your testing from there. When you consider the permutations of configurations typical test teams need to test, this will be a huge productivity enhancer.
Consistent feedback on the quality of the builds – the lab management solution allows you to configure your daily build system to build the product, deploy the application on an environment and execute tests on them. Effectively, this completely automates the daily BVT (Build Verification Tests) setup and provides a strong feedback on the state of quality of the daily builds.

Lab management also nicely plays along with the other VS2010 value propositions like rich data collection for bugs (snapshot the environment). For a developer, it is easy to debug a bug reported on a particular build (restore to the snapshot of the environment for that build) or to do smoke testing of his changes across various test configurations. For a tester, the environment is also a good starting point for exploratory testing, easily venturing into various corners of the product with the knowledge that a tester could always reach back a well known state.

Enough intro. This blog post series will walk you through the automation of the end-to-end workflow using a simple calculator web service and unit tests for the same. At the end of the post, we would see the automated workflow where triggering a build will build an app, deploy it to a VM, run tests on it and report results.

While this example does not use multiple VMs in an environment, the same experience is applicable for multi-tier app testing as well. We can extend the application under test to cover various topologies (from traditional backend / frontend to software NLB to VMs spanning multiple trust boundaries)

Prereqs:

One x64 hypervisor enabled machine with 4GB RAM that can act as hosts for the test VMs, as well as the SCVMM server. Note that SCVMM requires to be installed on a machine joined to domain and needs live connection to the domain for authentication. So this cannot be your roaming laptop.
1. Note that the server should be running x64 OS
2. Hardware-assisted virtualization and hardware-assisted data execution protection are enabled in the BIOS (if you changed them now, turn off the power of the machine and restart them). This post explains how to verify these settings in bios.
3. Hypervisor server role is installed
One x86 machine (2GB RAM) that can run TFS, VS and the build and test controllers for managing distributed build and test.

Representing the host configurations pictorially, you can configure your systems to be in either of the configurations below.

Software downloads:

Visual Studio 2010 Team Foundation Server: here
Visual Studio 2010 Team Agents Beta 2: here
Visual Studio 2010 Ultimate: here
System Center Virtual Machine Manager 2008 R2 RTM: here
VM creator tool from Codeplex: here
Windows Server 2008 R2 vhd: here (only needed if you do not have a server VM for OS VMs)

As part of the walk through we will

Configure SCVMM which is the management hub for virtual machines and the test VM (this post)
Install and configure TFS, the controllers to manage build / test and lab (Part 2)
Build the application under test in VS (Part 3)
Use the virtual lab we built out to automate the build / deploy and test experience (Part 4)

Install and configure SCVMM Server:

On the hypervisor machine (in my case varadademo.fareast.corp.microsoft.com), install both the SCVMM server and the Administrator console. The lab product uses SCVMM as the hub for driving all the VM related operations.

I have done the default installation. As part of the install, I had VMM install SQL Server Express.

VMM installs a SQL server that requires to be updated with some security patches. Use Windows Update to pick up the latest patches for VMM and SQL Server and reboot the machine after the updates are installed.

Launch the admin console, pair to localhost:8100

Select Add host and add the host machine (the same machine where I am running SCVMM)

Add test VM to the host:

Copy the Win2k8 R2 vhd you downloaded before to the library share and create a VM.Join the VMs to domain, giving it right computer names, and any other typical setup you might want on the VM. (Windows update to pick up the latest patches).

In a single host setup (with 8GB configuration), you can host the test VM and the TFS VM on the same host. In this case, make two copies of the VHD and deploy them to the same host. A future post explains how to build out the test VM (and TFS VM as well if you are configuring in a 8GB setup)

Configure the Test VM:

In our example, we will use the test VM as a web server to host our app and test it via unit tests. So let us make sure that ASP.NET is configured. To keep the walk through simple, we will just install all the web server components. Logon to the test VM, and from a elevated command prompt,

C:\Users\Administrator>servermanagercmd -install Web-Server -a

Servermanagercmd.exe is deprecated, and is not guaranteed to be supported
in future releases of Windows. We recommend that you use the Windows 
PowerShell cmdlets that are available for Server Manager.

Start Installation...
[Installation] Succeeded: [Web Server (IIS)] IIS Hostable Web Core.
[Installation] Succeeded: [Web Server (IIS)] IIS Management Scripts and Tools.
[Installation] Succeeded: [Web Server (IIS)] IIS Management Console.
[Installation] Succeeded: [Web Server (IIS)] Management Service.
[Installation] Succeeded: [Web Server (IIS)] FTP Service.
[Installation] Succeeded: [Web Server (IIS)] Custom Logging.
[Installation] Succeeded: [Web Server (IIS)] IIS 6 Metabase Compatibility.
[Installation] Succeeded: [Web Server (IIS)] Static Content.
[Installation] Succeeded: [Web Server (IIS)] Logging Tools.
[Installation] Succeeded: [Web Server (IIS)] Tracing.
[Installation] Succeeded: [Web Server (IIS)] Request Monitor.
[Installation] Succeeded: [Web Server (IIS)] IP and Domain Restrictions.
[Installation] Succeeded: [Web Server (IIS)] Request Filtering.
[Installation] Succeeded: [Web Server (IIS)] URL Authorization.
[Installation] Succeeded: [Web Server (IIS)] IIS 6 WMI Compatibility.
[Installation] Succeeded: [Web Server (IIS)] Dynamic Content Compression.
[Installation] Succeeded: [Web Server (IIS)] Static Content Compression.
[Installation] Succeeded: [Web Server (IIS)] Windows Authentication.
[Installation] Succeeded: [Web Server (IIS)] Basic Authentication.
[Installation] Succeeded: [Web Server (IIS)] ODBC Logging.
[Installation] Succeeded: [Web Server (IIS)] IIS Client Certificate Mapping Authentication.
[Installation] Succeeded: [Web Server (IIS)] Client Certificate Mapping Authentication.
[Installation] Succeeded: [Web Server (IIS)] Digest Authentication.
[Installation] Succeeded: [Web Server (IIS)] Default Document.
[Installation] Succeeded: [Web Server (IIS)] Directory Browsing.
[Installation] Succeeded: [Web Server (IIS)] ISAPI Filters.
[Installation] Succeeded: [Web Server (IIS)] HTTP Errors.
[Installation] Succeeded: [Web Server (IIS)] HTTP Redirection.
[Installation] Succeeded: [Web Server (IIS)] HTTP Logging.
[Installation] Succeeded: [Web Server (IIS)] ISAPI Extensions.
[Installation] Succeeded: [Web Server (IIS)] Server Side Includes.
[Installation] Succeeded: [Web Server (IIS)] CGI.
[Installation] Succeeded: [Web Server (IIS)] FTP Extensibility.
[Installation] Succeeded: [Web Server (IIS)] IIS 6 Management Console.
[Installation] Succeeded: [Web Server (IIS)] .NET Extensibility.
[Installation] Succeeded: [Web Server (IIS)] WebDAV Publishing.
[Installation] Succeeded: [Web Server (IIS)] IIS 6 Scripting Tools.
[Installation] Succeeded: [Web Server (IIS)] ASP.
[Installation] Succeeded: [Web Server (IIS)] ASP.NET.
<100/100>

Success: Installation succeeded.

Allow the VM to be managed remotely by enabling firewall exception for WMI

The next step will bootstrap the agents (test, build and lab) on the VM to allow the VM to participate in the end to end deployment workflow. As part of the configuration, build agent, test agent and lab agent will be installed and configured on the VM.

On the SCVMM machine, copy the isos of agent, TFS and lab (lab comes from the VMtool that you downloaded from here) to the SCVMM library share

move VS2010B2TFS1.iso "C:\ProgramData\Virtual Machine Manager Library Files"
move VS2010B2Agent1.iso "C:\ProgramData\Virtual Machine Manager Library Files"
move labmgmt.iso "C:\ProgramData\Virtual Machine Manager Library Files"

Go back to SCVMM Admin console and refresh the library shares and make sure that the new ISOs are visible there.

Now go to the directory where you have extracted the VMTool. Change the Inputfile.xml there to provide the VMMServer, LibraryShare, the admin user name and password for the running test VM and the rest of the information. (If you are using the Win2K8R2 vhds, the admin name is: Administrator, Password is: Pass@word1)

C:\Users\lmtstlab\Desktop\VMTool> type .\Inputfile.xml 
<Parameters> 
    <VMMServer>varadademo.fareast.corp.microsoft.com</VMMServer> 
    <LibraryShareName>MSSCVMMLibrary</LibraryShareName> 
    <VMName>VaradaB2VM1</VMName> 
    <VMAdminUserName>Provide Admin user name for the VM</VMAdminUserName> 
    <VMAdminPassword>Provide password for the admin user on the VM</VMAdminPassword> 
    <TFSISOName>VS2010B2TFS1.iso</TFSISOName> 
    <DTEISOName>VS2010B2Agent1.iso</DTEISOName> 
    <GoldenTemplateName></GoldenTemplateName> 
    <Owner></Owner> 
    <LABMGMTISOName></LABMGMTISOName> 
</Parameters>

Verify the VM is running and has network connection. Back at the SCVMM host, launch the VMM Powershell as administrator

Windows PowerShell
Copyright (C) 2009 Microsoft Corporation. All rights reserved.

PS C:\Windows\system32> set-executionpolicy Unrestricted

Execution Policy Change
The execution policy helps protect you from scripts that you do not trust.
Changing the execution policy might expose you to the security risks described
in the about_Execution_Policies help topic. Do you want to change the execution
 policy?
[Y] Yes  [N] No  [S] Suspend  [?] Help (default is "Y"): y
PS C:\Windows\system32> cd C:\Users\lmtstlab\Desktop\VMTool
PS C:\Users\lmtstlab\Desktop\VMTool> .\New-TemplateFromVM.ps1 .\InputFile.xml 
-SkipClone -SkipTemplateCreation
                 Connecting to SCVMM Server and initializing state...

At this point the test VM (VaradaB2VM1) is ready to participate as a virtual environment in the lab workflow. Let us store this in the library to be used when creating environments.

Select the default server

and share to save and go.

We now have in the SCVMM library a virtual machine that can be used by the lab software to create test environments. Before you save the VM to library, you could also do any other prerequisite that your system under test might have. In this case, we wanted a web server, and thus we ended up doing nothing more than configuring the web server.

In the next blog in this series, we will work on configuring the VM that will act as the TFS server, the build and test controllers and VS machine.

New blog design

2009-11-03T12:16:00Z

As you may have noticed, the design of the blog has changed. Primary motivation of this redesign is to switch to a neutral white background which is best suited for the screenshots as well as reading longer text. Another is to give a touch of branding.

The header uses signature colors of the Visual Studio brand, which in turn simply employs these primary and complementary Microsoft brand colors.

The primary background for the Visual Studio identity system consists of two elements: the primary color gradient and the white particle wave. Each of these elements may be used independently, but the combination of the two is the preferred background for Visual Studio brand communications.

The white particle wave is a flexible, infinite grid of translucent white dots that evokes the integrated nature and functionality of Visual Studio. Its dynamic, flowing shape is maximized to create an inspirational visual metaphor for the millions who make up the developer community.

The timeline in header depicts the evolution of technology in general - right from ancient abacus, punch cards and tapes of yester years, to PC and explosion of web, all the way to the next big thing 'virtualization'. The layout is optimized to give more space and visual prominence to blog posts and relatively less to navigation links.

We hope you will enjoy the new design.

Announcing Visual Studio Team Lab Management 2010 Beta2

2009-10-20T19:31:28Z

Visual Studio 2010 / .NET 4.0 Framework Beta2 was announced yesterday. MSDN subscribers can download it immediately with general availability on Oct 22nd. Visual Studio Lab Management 2010 is available as part of this beta release. There are numerous improvements in Lab Management Beta2 release as compared to Beta1 release, with some of the significant ones listed below:

Improved setup and configuration experience
Simplified Environment creation and edit experience
Full-screen environment viewer
Out of the box template for application build-deploy-test workflow
Network isolation with support for domain controller Virtual Machines
“In-Use” support for shared environments

To setup and configure Lab Management, follow this link for the relevant documentation. Lab Management usage documentation is available here. Note that Lab Management Beta2 requires System Center Virtual Machine Manager (SCVMM) 2008 R2 RTM that you can download from here.

To discuss setting up and usage of Lab Management, post your queries on the Visual Studio Lab Management discussion forum. If you have found a bug or would like to file a suggestion for future versions, please visit the Microsoft Connect Beta 2 feedback page.

In the coming weeks, we will be publishing a series of blogs on this site that go deeper into various usage scenarios. Do visit us often and share your feedback.

Enable Lab Management features for existing Team Projects in Beta2

2009-10-19T14:15:00Z

Important: The instructions in this post only apply to the Beta2 version of Team Foundation Server 2010. For Beta1, see this post.

If you are upgrading your Visual Studio Team Foundation Server (TFS) 2008 to Visual Studio Team Foundation Server 2010 Beta2 and want to enable Lab Management features for your existing projects you will need to follow a set of steps. This blog post covers details about these steps.

So, first upgrade your TFS server. Then you can configure Lab Management using TFS administration console and start using these features for new projects. To enable Lab Management features on existing team projects use the following steps.

Pre-requisites

Install SCVMM server and add lab hosts to host groups. For more details see How to: Set up and Configure Virtual Machine Manager.
Install SCVMM admin console on TFS application tier machine. For more details see How to: Configure or Reconfigure Lab Management in Team Foundation Server Application Tier
Enable Test Case Management for the project. See Hakan’s blog for a sample script to easily enable Test Case Management features on an existing project.

Step 1 - Configure Lab Management

You can configure Lab Management by using the administration console for Team Foundation.

Click Start, All programs, Microsoft Team Foundation Server 2010 Beta 2, and then click Team Foundation Administration Console.
In the Administration Console, in the Application Tier node, click Lab Management.
Click Configure Lab Management.
On the Virtual Machine Manager tab, in VMM Server Name, type the name of the server that is running Virtual Machine Manager and that you will use to manage the virtual machines.
Click Test to determine whether Visual Studio Team Foundation Server can communicate with the VMM server.
1. If Team Foundation Server service account does not have the appropriate permissions on the specified VMM, a dialog box prompts you for your username and password.
2. Specify the credentials of an existing member of VMM Administrators Role. Using this username and password, the Team Foundation Server service account will be added to the VMM Administrator Role.
  - If Team Foundation Server cannot contact the VMM server, a red x and an error message will appear.
In Network Location, select network location from the drop-down list. Click OK.
- If network location does not appear in the list, then follow the steps in How to: Set Up and Configure Virtual Machine Manager to verify that network location has been determined and made known to VMM.

Step 2 - Configure Lab Management for the Project Collection hosting upgraded projects

Click Start, All programs, Microsoft Team Foundation Server 2010 Beta 2, and then click Team Foundation Administration Console.
In the tree pane, click the Team Project Collections node under Application Tier.
Select the project collection hosting upgraded projects.
Click on Lab Management tab for the selected project collection.
In the results pane, click Configure Library Shares.
Click Add, select one or more VMM library shares that this team project collection will use, and then click Add. You can add a library share to only one team project collection at a time.
Now to configure Host Groups for this collection, select Host Groups tab.
Click Add, select one or more host groups that this team project collection will use, and then click Add.
Click Verify to verify the status of selected host groups. Click OK.

Step 3 - Configure Lab Management for upgraded Team Project(s)

Download the zip file attached to this post, and extract it to a local directory such as C:\Upgrade.

Before you run the script, open “EnableLabManagement.bat” in a text editor and complete the configuration by specifying values for the following:

Team Foundation Server URL
Name of the team project collection
Name of the team project
Path to TFSLabConfig.exe utility
Set ConfigComplete = 1 to indicate that you’ve completed this step

This script will grant default Lab Management permissions to standard security groups, ex. Readers, Contributors, Project Administrators and Project Collection Administrators.

Rerun the batch file for each existing project, after updating project name in the batch file.

- Vishal Mehrotra

[Edit] - Modified the script as per the updated syntax.

Test applications on virtual environments and file rich bugs

2009-07-09T00:43:25Z

You are testing a complex multi-tiered application. You create different configurations, multiple data sets, and test the different combinations in a user-flow. You come across a hard-to-find bug. You file it and are pleased that your effort was well worth it. But the next morning you realize that your developer has resolved your bug as 'No repro' with the comment 'It works on my box'. You are really frustrated and determined to reproduce the bug again and file it, this time with a screenshot and logs. And the bug ping-pong continues. Does this ring a bell??

Testing and development can be so much more efficient if the bug you filed was rich and actionable in the first place. With Team System 2010, you can automatically create highly actionable bugs with video, screenshots, system info, event logs, and many other types of logs.

Well, there are these nasty configuration issues that will still be hard-to-reproduce for the developer on his environment. What if you could attach the environment snapshot with the bug itself, so the developer can connect to the machines in the same state as they were when you found the bug, and reproduce the problem?? We have good news - with lab management, you can do exactly that. Let's find out how.

After reading this article, you'll be able to:

Configure your virtual environment to run tests.
Run manual tests on the application deployed in the environment.
File a rich bug with your virtual environment snapshot attached to it.

This article is divided into two parts. The first part talks about how to create a virtual environment for testing. And the second part talks about how to run manual tests on the virtual environment and file actionable bugs. Before we end, we'll also show you what the rich bug looks like to the developer and how he can use it.

I. Setup a virtual environment for testing

Here is a block diagram of Lab Management components. To be able to run tests and collect logs from environments, you need to first install and configure a test agent controller with your TFS Team Project Collection. Next, you need to install test agent and lab agent on the virtual machines that'll be a part of your environment. You can import the virtual machine and create environment that is ready for testing. Finally, create a test settings that specifies the different logs to be collected from various roles of the environment while you test your application.

1. In order to run tests and collect logs from environments, you need to first setup your test agent controller. The steps to install a test agent controller and configure it with your TFS Team Project Collection are described in steps 15-17 of the Lab Management Beta1 setup guide.

2. The next step is to install agents on the virtual machines that'll be part of your environment. This can be done when you create virtual machines from SCVMM. You need to install test agent and lab agent on the virtual machines to be able to collect logs and run tests on these machines. Steps 20 and 21 of the setup guide describe how to install lab agent and test agent on the virtual machine.

3. Import virtual machines and create environment: This post describes how to import a virtual machine in lab as a 'virtual machine template' and create an environment with it. These steps can also be founding in the 'Create a virtual environment' section of setup guide.

While you are creating the virtual environment, ensure that on the 'Advanced' page, the testing capability is turned on, and the test agent controller you setup has been selected.

Start the environment and ensure that there are no errors. Once the machines in the environment have started and the testing capability status is 'Ready', you are all set to run tests on the app deployed in the environment.

4. Create test settings: Finally, you need to create a test settings that define what logs to collect (and also where to execute tests in case of automated tests) while you run your tests. You now create a new test settings for the roles in your environment.

Open Microsoft Test and Lab Manager (henceforth called MTLM) and go to 'Lab Center' -> Test settings. Click on 'New' to create new test settings.

Enter name and description. Choose testing type as manual (to be used to run manual tests) and select the option to 'Additionally collect data or perform system actions on remote machines using an environment'.

Go to 'Environments' page. Select the environment you created.

Skip the 'Test machines' page and go to 'Data and diagnostics'. Here you can define what logs you want to collect while the tests are running. 'Local' refers to the machine from which you'll run the tests using test runner. Click on the various roles and define the logs you need to be collected.

Verify the settings in the 'Summary' page and click Finish to create your test settings.

So far, we have seen how to configure the virtual environment to run tests and created a test settings. The next section talks about actually running the tests on the virtual environment and filing rich bugs.

II. Run tests and file actionable bugs

You have created your virtual environment and deployed your application on the environment using the workflow. In the meanwhile, the test team has created a test plan for this iteration of the product cycle and added test cases to it. You are all set to test the application. Now, we'll find out how to run manual tests on an application deployed in the virtual environment and create highly actionable bugs, which reproduce for the developer.

Run tests and file rich bugs

1. Go to the Testing Center in MTLM and select the Test tab. Select your test plan and the set of test cases you want to run. Click on "Run with options " and choose your test settings and virtual environment.

2. The Test Runner window is launched (by default it will be docked to the left side of the screen). Click on "Start test". Launch your client window (IE/rich client) and start running the steps in your test case.

3. While running your test cases, when you find a 'hard-to-repro' bug, you can take a snapshot of the environment by clicking on "Take Snapshot" action under "Lab Actions". The snapshot operation will take around 15-30 seconds. Once the snapshot is completed, you can observe the .lvr file (link to the snapshot) in the bottom pane.

4. Now, create a new bug for the problem you just observed by clicking on 'New bug' action in the toolbar. In the new bug dialog, you can see that the repro steps are automatically filled in from your test case. The 'System Info' tab has information about your local machine as well as the test machines in the environment. Also note that the 'Other links' tab has the different logs from your environment as configured in your test settings and the link to the environment snapshot (.lvr file). Enter a title and save the bug.

5. As you are running your test cases, note that you can connect to the virtual machines in the environment using the "Connect to Environment" option under "Lab Actions" menu. Also note that the .lvr file just has a link to the environment snapshot. The link will be resolved dynamically while the developer clicks on it. The size of the link is only around 1 KB. The actual snapshots are stored on the Hyper-V hosts itself, and use the differencing disk technology to store the changes from last snapshot only. Hence you can attach multiple snapshots to a bug, if needed.

6. Once you are done with testing, click "Save and close" to save the results and restore back to MTLM window.

Debugging using environment snapshot

1. Launch Visual Studio 2010. Connect to your Team Project using Team Explorer. Open the query 'Active bugs' under 'Work Items -> Team Queries' and open the bug you just filed.

2. If you go to the "Other Links" section of the bug, you will notice that it contains the link to the snapshot of the environment. Double click on this file to connect to the environment snapshot.

3. You will see a dialog with multiple options to connect to the environment. Let's spend a moment to understand what they mean.

a. "Connect to the saved snapshot in this environment" - Use this option if you want to restore the exact state of the virtual environment at which the snapshot was taken. If you choose this option, you might end up disconnect any user currently using this environment and this might lead to loss of their work.

b. "Connect to the Environment in its current state" - Use this option if you just want to connect to the virtual environment in its current state. There is a possibility that you might still disconnect someone connected to this environment, but you will not restore the environment's state.

c. "Connect to a new instance of this environment" - You can use this option to create your own copy of the environment. This way you will not disturb anyone using the environment currently. However, it will take few minutes for your new environment to be created and it is recommended to use 'Network isolation' capability on environments if you intended to run multiple copies of it.

Note that this option is only available to you if you have stored your virtual environment in the library as a template. You can do so from Lab Center -> Environments and choosing 'Save as Template' action on the environment. If the environment hasn’t been stored in the library, this option is not available.

4. Choose the most appropriate option and click on 'Connect'. This brings up the lab environment viewer and connects you to the machines in the environment. You can now login to the machines, reproduce the error, and debug its root cause.

To sum up, you have seen how you can configure your virtual environment for testing, how to run tests and file rich bugs, with environment snapshots so that the developer can always reproduce the problem and debug it.

We hope you liked this and look forward to hear your comments.

Darshan Desai, Program Manager and Bhuvaneshwari K, SDET

Visual Studio Team Lab Management

Creating Virtual Machines for Lab Management

2009-07-03T14:16:00Z

To create virtual environments in Microsoft Test and Lab Manager, you first need to have virtual machines in your project library share. Lab Management does not provide the functionality to create fresh virtual machines. You have to use Hyper-V or SCVMM in order to create these initial or golden virtual machines, and then "import" them into a project. The import in Beta1 is done by 'creating a new virtual machine' using Microsoft Test and Lab Manager.

Before moving further, let me clarify that the terminology used in Beta1 is changing for our next release. A lot of customers said that they were confused about the use of our phrase 'create new virtual machine' in library. For this blog, I will make two clarifications and continue to use Beta1 terminology. First, when we "create a new virtual machine" in a project library share, we are just importing a virtual machine managed by SCVMM into lab. We are not really creating a fresh copy of the virtual machine. Second, our term virtual machine in project library share can refer to either a Virtual Machine or a Virtual Machine Template in SCVMM. Thanks to your feedback, we are going to clean this up and remove some of the confusion surrounding this in Beta2.

Coming back to our topic, in order to import a VM into lab, you either need to have a virtual machine or a virtual machine template already in SCVMM library. So, the question is, how to create a VM or a VM template in SCVMM library?

There are several ways and some of our customers (especially those who are new to SCVMM) were asking for best practices around this. In this blog, we will talk about some of these practices. If you have discovered something else that works for you, please share it with us and the rest of the community.

Starting point

In order to create a VM or VM template in SCVMM, you can start from one of the following:

(a) Scratch: You have got nothing. You want to create a fresh VM, then install OS, and any applications + agents into that VM.

(b) An existing VHD: You have a VHD that already has the OS, applications, and agents installed. You need to turn this into a VM or VM template that can be later used in Lab Management.

(c) An existing physical machine: You have a physical machine that you want to convert into a virtual machine and then use that to create environments in Lab Management.

Target

You need to decide whether you would like to import a VM or a VM Template -

You can think of the VM as a 'fully baked' computer. It will have OS, apps, and agents installed; it has a computer name, an IP address, etc. When you import a VM into lab and use it to create several copies of environments, you need to use network isolation - a feature in Lab Management that prevents network conflicts. The advantage of using VMs is that you will get exact replicas of what you have created and it saves you time from re-installing or re-configuring your application.

A VM Template is a 'half baked' computer. The OS inside the VM is generalized by running a tool called Sysprep, which essentially removes the instance specific information from the image. When a VM Template is imported into lab, you can use it create multiple copies of the environments without network isolation feature. Each copy of the VM is customized with a unique computer name so that there are no network conflicts.

To summarize, create a VM in SCVMM library if you plan to use network isolation or don't plan to clone environments. Create a VM Template in SCVMM library if you do not plan to use network isolation.

Recommended approaches for creating VMs and VM Templates

The following table shows the starting points on the left and targets on the top. Find the box that suits your needs and see the recommended approach for creating a VM or VM Template. Each step is usually a hyperlink to more detailed documentation in SCVMM or Hyper-V.

Target

-----

Starting point

Virtual Machine

Virtual Machine Template

Scratch

Using SCVMM Admin Console

Create a VM on a host from a blank disk using SCVMM.
Install OS, software, and agents in the VM.
Shutdown the VM.
Store the VM to a SCVMM library share that is used for Lab Management.

(OR) Using Hyper-V Manager

Create a VM from a blank disk using Hyper-V.
Install software and agents in the VM.
Export the VM to a SCVMM library share that is used for Lab Management. To do this, right click the VM in Hyper-V manager, and click on Export.
Fix the ScopeOfResidence if the Hyper-V host is not Windows Server 2008 R2 (see Additional notes below).

Using SCVMM Admin Console

Create a VM on a host from a blank disk using SCVMM.
Install OS, software, and agents in the VM.
Shutdown the VM.
Create a template from the VM and select a library share that is used for Lab Management.

Existing VHD

Using SCVMM Admin Console

Copy the VHD to a SCVMM library share.
Create a VM in library share from an existing disk using SCVMM. Select the library share that is used for Lab Management.

Using SCVMM Admin Console

Copy the VHD to a SCVMM library share that is used for Lab Management. The VHD should already have the OS installed and identity information removed using the Sysprep tool.
Create a template from the VHD.

Physical machine

Using SCVMM Admin Console

Convert a physical machine into a virtual machine.
Store the VM to a SCVMM library share that is used for Lab Management.

Using SCVMM Admin Console

Additional notes:

In all the above, use the same SCVMM server that is used for Lab Management as well.
Wherever mentioned copy the object to the same SCVMM library share that is used for Lab Management.
If you create a VM template, do not set sensitive information such as Administrator password, Domain credentials, and Product key using SCVMM. When the VM template is imported into Lab Management, this sensitive information is dropped.
This article does not cover how to install lab or other agents into your golden VMs. For more information about this, please refer to the lab setup guide.
Whenever you use Hyper-V to create a VM and export it, you have to perform the following additional steps to be able to use the VM from SCVMM or Lab Management.

Go to the Virtual Machines folder in the export location (say C:\export\My VM\Virtual Machines) and open the <guid>.exp file in a text editor.
Search for the tag <ScopeOfResidence> within that file. Clear the value that exists between the <Value></Value> tags. The following screen shows an example of this.
Save the file.

What's next?

Now that you have a VM or VM template in SCVMM library share, go to Microsoft Test and Lab Manager -> Lab Center -> Library -> Virtual Machine Templates and import it by clicking on 'New'. Once the VM or VM Template is imported into lab, you can use it in creating environments.

Networking basics for lab management - Part I

2009-06-08T11:48:00Z

How are the virtual machines in a Lab Environment connected to each other and to other machines? Can I have physical hosts that are distributed across networks? What is the significance of network location in Team Foundation Administration Console? What if I want more control on how virtual machines are networked? If I turn on network isolation capability, what happens to the network of an environment? We will try to answer questions such as these in this series on 'networking basics for lab management'. Some of this information is useful for lab administrators in planning the physical network topology of the lab. Knowledge of how environments are networked allows development teams understand how their applications might behave when deployed into a virtual Lab Environment.

Physical networking

Before getting into networking of environments, let us spend some time on the networking of lab infrastructure machines - physical hosts, library servers, SCVMM server, TFS server, and Test and build controller machines. Needless to say, there has to be IP connectivity between all these machines. SCVMM communicates with its agents residing on physical hosts and library servers. TFS server communicates with SCVMM and with test/build controller machines.

The clients from which you run "Microsoft Test and Lab Manager" or VSTS need IP connectivity with TFS and with test/build controller machines.

While having IP connectivity between the machines is the minimum requirement, there is more you need to do to get good performance. It is highly recommended that all the physical hosts and library servers have Gigabit Ethernet connectivity to each other. This means that all of them should have Gigabit Ethernet cards, and should be directly connected to a shared Gigabit networking switch. This ensures that the data transfers (think of the large VMs that get copied from one machine to another) between them happen with acceptable performance. As an example, copying an Environment of size 30 GB from a library server to physical host over BITS (Background Intelligent Transfer Service - this is the protocol used by SCVMM to copy VMs) may take about an hour in a 100 Mbps network, and around 10 mins in a Gigabit network. To accommodate larger labs, you can use multiple switches. The idea is to keep the end-to-end bandwidth between hosts and library servers close to a Gigabit.

This guidance implies that all the hosts and library servers are on the same network segment. If you have a larger lab or if you need to distribute physical machines across network segments, Lab Management allows you to do that. You can still get the desired performance by having a Gigabit network within each segment and carefully grouping the hosts that are co-located into a SCVMM host group. By allocating such host groups and co-located library servers to Team Projects, you can ensure that data transfers only happen between machines that are connected on a Gigabit network.

Networking on a host

Each physical host in the lab may be connected to multiple networks. Multiple networks are typical for separating data traffic and management traffic. For each network that a host is connected to, there is a network location that identifies that network. Using SCVMM, you can see the number of networks each host is connected to and their network locations. Select the host in VMM admin console and view its properties. The following figure shows a host that has four network network adapters, but is connected to only one network.

The 'location' of that network in this example is corp.microsoft.com. If the network location is empty, you can click on the 'Override discovered network location' checkbox, and type in the name of a location. Before running lab, you need to ensure that all hosts are connected to a common network location.

Use the TFS admin tool to configure this common location as the 'preferred network location' for lab.

The preferred network location identifies the network to which all virtual machines created by lab should be connected to. And, the network adapter on a host that is connected to the preferred network location is called preferred network adapter for that host.

PS1: In VSTS Lab Management 2010 Beta1, if you change the network location after setting it once, you have to reset IIS and restart the TFS job agent service on TFS machine. This is fixed post Beta1.

PS2: If you change the network location after setting it once, virtual machines that are already deployed are not affected. In other words, they remain connected to the old network location. To make them connect to the new location, you have to store the environments in library, and redeploy them. Or, more simply, you (admin) can use SCVMM and manually change the connectivity of each VM.

One more thing that you need to ensure for every physical host is that it has an external virtual network that is connected to the preferred network adapter. You can check this by using the Hyper-V manager or SCVMM admin console. The figure below shows the Hyper-V manager on a host. By clicking on the Virtual network manager, you will be able to see all the virtual networks that are configured on that host. Hyper-V supports three forms of virtual networks - external, internal, and private. Ensure that there is one virtual network that is marked as external and is connected to the preferred network adapter.

You can easily verify that each host in a host group is properly networked by using the Team Foundation Administration Console. When you add a host group to a Team Project Collection or when you open an existing Team Project Collection that is configured for Lab Management, you can verify that all hosts in the host group satisfy the above networking requirements. Open the Project Collection level Lab Management Settings by clicking on 'Configure Host Groups' as shown in the figure below, and press the 'Verify' button.

Networking for an environment

Now that we have the hosts physically networked and lab configured in TFS, we are all set to understand how environments are networked in VSTS Lab Management. In this post, let us focus on environments that are not network isolated.

Let us say we created an environment with two virtual machines. VSTS Lab Management ensures that each of the virtual machines has one emulated network adapter that is connected to the preferred network location as shown in the figure below. If this means that a new network adapter has to be created and attached to the virtual machine during the creation process, VSTS Lab Management does so.

To walk you through the above figure, there are two physical hosts A and B. The preferred network location configured in Team Foundation Administration Console is 'corp.microsoft.com'. One Lab Environment with two virtual machines has been created. Lab Management placed the first virtual machine (VM1) on Host A, and the second virtual machine (VM2) on Host B. N2 is the preferred network adapter on Host A, since it has a network location that matches the lab's preferred network location. N1 is the preferred network adapter on Host B. Lab Management connects VM1 to an external virtual network of N2 on Host A. VM2 is connected to an external virtual network of N1 on Host B.

More flexible networking for an environment

What if you wanted your environment to be connected to a second network location (say test.microsoft.com in the above example) in addition to the preferred network location? Lab Management does not currently expose this flexibility through its APIs or client. However, you can get around this by using SCVMM. This is what you need to do. When creating the VM in SCVMM, insert a network adapter into the VM and set its network location to 'test.microsoft.com'. The following figure shows how you can do that in SCVMM. While creating a new virtual machine, configure the network location of an adapter to be 'test.microsoft.com' under the 'Configrue Hardware' step.

Now import this VM into lab. When an environment is created from that VM, VSTS Lab Management inserts a new network adapter into the cloned VM with network location set to 'corp.microsoft.com'. As a result, the newly created VM will end up with two network adapters - one connected to 'corp.microsoft.com', and one connected to 'test.microsoft.com.

Questions, Comments, Feedback?

Our goal was to provide a simple experience for the testers and developers using Microsoft Test and Lab Manager, and not to burden them with the intricacies of networking their environments. Hence, we made it easy for the most common case, where all virtual machines in an environment are connected to one network. For certain other complex situations, SCVMM can be used to configure the networking of a VM before it is imported into lab.

We would like to hear from you. Does this networking scheme satisfy your application needs? What other features would you like to see? If you have more questions or comments, please post them to this blog.

In Part 2, I will describe how the networking of a 'network-isolated' Environment looks like.

Creating and Working with Virtual Environments

2009-06-02T08:36:00Z

Today as we build more and more complex applications the complexity of development and testing environments have increased significantly. Development and testing of complex N tier application on single machine results in late discovery of bugs in pre-production or worse in production environments. Ideally we would like to develop and test applications in an environment which is as close to production as possible (due to cost and other infrastructure limitations we may never get identical). Unfortunately today setting up these N tier environments on physical machines is a time consuming and error prone process and keeps dev/tests focus away from their core activities. This results in not only loss of productivity but also impact product quality.

VSTS Lab Management supports creation of virtual environment in minutes as oppose to days. This allows development and test teams to develop and test code against production like environments without spending days in setup which results in improved productivity and quality. As setting up these environments is so easy, it encourages sharing of hardware resources across the team and self service as oppose to dependence on a IT Administrators. With sharing and self service your total cost of ownership of running labs reduces significantly. In this post we’ll cover how to create and work with virtual environments.

A virtual environment is defined as a collection of virtual machines (VM). e.g. a typical 3 tier application environment will have 3 virtual machines namely client , web server and database server. In order to create this environment you first need the individual virtual machines which can play different roles as mentioned above namely client, web server etc.

Since majority of applications will have similar needs as above, Lab Management enables you to create these basic virtual machines (also known as Golden VMs) once and store in the library as virtual machine templates so that any time you want to create an environment you can reuse these virtual machine templates.

Creating Virtual Machine Template

1. First step is to have the base virtual machine which you want to use as virtual machine template (Golden VM) for different environments. If you already have a virtual machine just copy the virtual machine folder with all the necessary files into the System Centre Virtual Machine Manager (SCVMM) library share. In case you do not have a virtual machine you can easily create one using SCVMM Admin Console which comes with Lab Management SKU (we will cover this in more detail in one of the upcoming posts).

2. Now launch “Microsoft Test and Lab Manager” from All Programs -> Microsoft Visual Studio 10.0 -> Microsoft Test and Lab Manager

3. Connect to the TFS Server and your team project. Click on “Don’t Set context” when prompted. Go to Lab Center (from top left) and click on “Virtual Machine Templates” on the ‘Library’ activity.

4. Click “New” to create a virtual machine template. This opens up the wizard where first you need to select the library share where you want Lab Management to store this virtual machine template.

5. Then select the virtual machine from SCVMM library share by clicking the browse button. The below list shows the virtual machines which you have created earlier either using SCVMM Admin console or copied into SCVMM library share (in case you already had virtual machine).

In this list you only see virtual machines available in SCVMM library shares. So if you have existing VHD which you want to create a virtual machine template from, use SCVMM to create a VM using this VHD, and store it in the library.

6. After selecting the virtual machine now you can enter the name and description for this virtual machine template. Also you can assign a role to help select appropriate virtual machine template during environment creation e.g. all the virtual machine templates with different configurations (version, OS etc) of SQL server can be assigned role as “Database Server”. Similarly all the virtual machine templates with different configurations (version, OS etc) of IIS server can be assigned role as “Web Server” etc.

7. That's it!. Just press finish and you have created your first virtual machine template as you can see in your list of virtual machine templates.

8. Repeat above steps to create another virtual machine template for IIS Server.

Creating Virtual Environment

Now as you have created virtual machine templates (Golden VMs) you are all set to create your first virtual environment. Majority of team members in your team can start directly here as once someone creates a set of virtual machine templates everyone can start using them to create environments.

1. Click on “Environment” activity in Lab Center. Click “New” to create a new environment.

2. Provide a name and optionally a description for the environment you are about to create. Let’s give it a name “Dinner Now Test Environment” as we will use this for testing Dinner Now application.

3. Select Virtual as the type of environment

4. Select one of the host groups from the host group drop down list & click “Next”

5. From the list of available roles, select the Database Server role and the Web Server role, by clicking on each and then clicking on the Add button. Note that you can also add your own roles by clicking on the New Role button on top of the roles lists. Click “Next”.

6. Assign a VM template for each of the roles. On the right side you can see the list of VM templates from library as created in earlier step. e.g. Assign VM template Win2k3-IIS to Web Server role and Win2k3-SQL to Database server role.

7. That’s it! Just press finish and your first virtual environment creation is started. Virtual environment creation may take several minutes depending on number and size of VM templates selected above.

Working with Virtual Environment

Like physical environment you can start, stop and connect to different machines of your virtual environment. In addition, virtual environment provides some advantages over physical environments such as snapshot & restore. You can take a snapshot of your complete virtual environment (data and memory state of all machines) at a point in time and later restore that snapshot. This is really useful to debug complex bugs which are difficult to reproduced on a developer machine as now developer has access to the environment with the same configuration, same build and same meta data when the bug was found. With this capability you can significantly reduce the no. of non-reproducible bugs. Stay tuned for more details on this scenario in an upcoming blog post.

To work with any environment you can just double click on any of the virtual machines of the environments and it opens up “Lab Environment Viewer” tool. This tool allows you to connect to different machines of the environment without remembering their names/IP addresses for terminal services (TS) sessions. Also Lab Environment Viewer shows you all the virtual machines on the left and avoid painful switching between TS sessions. While you are working on one of the machines you can also get a quick preview of other machines with the cool thumbnail view.

To start, stop, snapshot or pause an environment you can simply click the necessary action from the environment tool-bar at the top-left corner. when you perform an action it applies to all the virtual machines of the environment. So to snapshot a multi machine environment you just need to take snapshot for the environment as oppose to individually taking snapshot of each machine.

All the snapshots of the environment are available under snapshots tab of environment viewer. At any point of time you can revert your environment to any of these snapshots with a single click of revert and all the machines will be restored to that snapshot. e.g. you may want to take a snapshot after the environment is setup first time calling it “Clean state” and than deploying regular builds on this environment can be simplified significantly as you can revert the environment to clean state before every build deployment. Lab Management also offers great automation to automate regular build, deployment and test cycles.

Also at any point you can access to an older build with a simple revert to the snapshot of that particular build. This is really helpful when you need a prior build for debugging a issue as unlike with physical machines where you may spend hours (to uninstall the current builds and then install new build and even then not sure if everything is fine as uninstall may have issues) now you can get to a prior build with just a button click “Revert to Snapshot”.

In this post we have covered the basic Lab scenario, of creating and working with virtual environment. Stay tuned for the next post about leveraging virtual environment for testing.