Appendix: Setting up the Infrastructure

On this page:

Download:

The testing infrastructure | What software do I need? | Configuration choices: spreading the software on the hardware - The components of the infrastructure, Lab Manager and virtualization | Example configurations - The non-starter setup, The economy setup, Separate server computers for high traffic, Separate file server for the VM library, More computers, Server components on virtual machines | Licensing | Service accounts - Service account usage | Installing the software | Installation overview | Hyper-V | Virtual machines for test infrastructure components - Your first virtual machine: installing Windows on a new blank VM (60 minutes), More virtual machines: creating a virtual machine by import (15 minutes) | Install System Center Virtual Machine Manager (SCVMM) - Prerequisites:, Install the VMM server, Install other bits, Connect to Hyper-V | Enable Microsoft .NET 3.5 and Internet Information Services (IIS) | Install SQL Server 2012 or 2008 R2 for Team Foundation Server - Enable TCP and Pipes protocols | Install SharePoint (if required) | Install Team Foundation Server - Configure Team Foundation Application Server, Set up Lab Management, Create a team project collection, Set up the build service, Allowing build completion emails | Connect to Team Foundation Server in Visual Studio | Add team members | Connect in MTM | Set up a test controller | Setting up physical and virtual machines for testing | Creating a virtual machine by using SCVMM | Where to go for more information

In this appendix, we've brought together all the stuff about setting up your environment for application lifecycle management with Visual Studio (with emphasis on the test tools). You won't need all of it when you first start, but we figure that, if you're the team's administrator, you'd prefer to have the instructions all in one place rather than spread throughout the book.

Here's what we'll cover in this appendix:

• The Testing Infrastructure – All the software components you'll have to assemble, and how to choose between the different ways of distributing them between boxes.
• Permissions – Licensing and service accounts.
• Installing the Software – How to install the features of Visual Studio that you will use for application lifecycle management.
• Populating the VM Library – How to create new VM templates.

We have provided a couple of popular paths through the forest of options. We suggest you begin with these and then tune things to your own project's needs when you have more familiarity.

You’ll see lots of tools and technologies referenced as you read through this appendix. Don’t worry; you can always access them by going to the online version of the bibliography. The URL can be found at the end of each chapter.

For a set of hands-on labs and detailed map of even more alternatives, you can download the Visual Studio Lab Management Guide. Also see Installing Team Foundation Components.

The testing infrastructure

What software do I need?

The features we've been discussing are provided by a combination of components, which together form the testing infrastructure. Here are the products you will use, in approximate priority order. We'll discuss the options in more detail shortly.

We have written this book with Visual Studio 2012 in mind. However, you can do nearly everything we describe with Visual Studio 2010—though sometimes less effectively or conveniently. We will note where there's a significant difference.

We used Windows 7 and Windows Server 2008 to create our examples, but Windows 8 will work just as well. Visual Studio 2012 has features specifically aimed at testing Windows 8 apps, but we don't talk about them in this book.

Product or Feature	Software and Version	For
Visual Studio 2012 or 2010	Visual Studio Professional	Unit testing, debugging. Team Foundation Server UI.
	Visual Studio Premium	All the above, plus code coverage, coded UI tests.
	Visual Studio *Ultimate	All the above, plus web performance, load tests, MTM.
	Visual Studio Test Professional	MTM. Team Foundation Server UI. No unit testing or debugging.
Microsoft Test Manager (MTM)	Installed as part of Visual Studio Ultimate or Test Professional	User interfaces to lab management, test planning, and test runner.
Windows	Windows Server 2008 R2 Enterprise R2 64 bit (includes Microsoft Hyper-V technology)	Servers running the testing infrastructure components. You need a license for each machine, even if it is virtual. (You do not need a license for short-lived test installations.)
	Windows 7	Desktop or laptop machines.
Team Foundation Server	Visual Studio 2012 or 2010 Team Foundation Server	Work item tracking, source control, build service.
System Center Virtual Machine Manager (SCVMM)	Virtual Machine Manager 2008 R2 SP1 or 2012	Virtual machines for test environments.
Microsoft SharePoint Server	*SharePoint Standard; or	Project website with basic reports.
	*SharePoint Enterprise	Extended reports and dashboards. See Dashboards on MSDN.
Microsoft SQL Server	SQL Server Express	Supports SCVMM.
	**SQL Server 2008 Standard	Supports Team Foundation Server. Provides reporting services – charts of team progress and product quality.
Key Management Service (KMS)		Provides activation keys to test virtual machines.

* If you need to economize, you can manage without SharePoint.

** You could use SQL Server Express to support Team Foundation Server. However, you should be careful with this decision; you can't easily migrate Team Foundation Server from one SQL Server edition to another, and you will lose the historical data in your work items.

Configuration choices: spreading the software on the hardware

What hardware do you need?

The quick answer is: Two or more big servers; the more the better; but the fewer, the more economical.

One big server is the test host computer. On it, you run virtual machines in which you perform your tests. If you want to run a lot of tests at the same time, you can add more test host servers.

The other server or servers are for the other components of the testing infrastructure: that is, the products such as Team Foundation Server that we've listed in the table above, together with their various auxiliary agents, services, and consoles.

If your project is large, you'll want to spread the infrastructure components out over several computers. To understand that better, let's discuss what the various parts do.

The components of the infrastructure

Whether you pack the components all into one computer, or spread them over many, their functions and relationships are the same:

The test infrastructure

In this diagram, all the boxes are software products, except for the test host computer and the physical test computers.

• Test host is a physical computer that runs Hyper-V. Virtualization allows several virtual machines to share the resources of the physical computer. You can have more than one test host computer so that many virtual machines can run at the same time. Hyper-V is a role of Windows Server that you can switch on in the Computer Management control panel.
  • Test host computers should have a lot of disc space, RAM, and logical CPUs. Virtualization divides these resources between the running virtual machines.
  • We recommend that you don't install any significant service on a test host except Hyper-V. Put the other products on a separate computer or computers.
  • It is possible to run tests without Hyper-V, but we recommend you use it because it makes it much easier to create fresh testing environments.
• Test virtual machines (VMs) are machines that your team will create for running tests. Each machine behaves almost exactly like a physical computer. For example, you can register it on your organization's network, start it and shut it down, open the console screen, or log into it with Remote Desktop. In addition, you can save its state and reset it to that state later; you can make duplicate copies of it, and store them in a library.
  • We recommend running tests on VMs because it is very easy to create new VMs with different configurations of virtual hardware, operating systems, and other software. It is also very easy to reset them to a clean state.
  • Most tests can be run on VMs; the exceptions are tests involving special hardware, and some kinds of performance tests.
  • You can use other virtualization frameworks, such as VMware or Citrix XenServer, to run VMs. However, you have to use their facilities to save and restore virtual test machines.
• Physical test computers are useful for performance tests, or tests that must run on specific hardware. But if this is the first time you've used virtual machines, you'll be surprised how infrequently you need the physical boxes. You'll come to find them inconvenient by comparison with virtual test machines. You can even run some types of performance testing on virtual machines.
• System Center Virtual Machine Manager (SCVMM) lets you combine multiple Hyper-V hosts into one big resource. You can create your own private cloud. It also lets you create a library of VM templates from which to create new virtual machines. After installing SCVMM, you don't need to work with the individual Hyper-V consoles.
• VMM agent is the proxy for SCVMM that is installed on each test host. Its job is to allow SCVMM to control Hyper-V.
• VM Library is a file store for copies and templates of virtual machines. Each virtual machine is typically several gigabytes in size. This file store therefore has to be huge, and should be on a disk by itself. The first VM library must be on the same computer as SCVMM, but you can add further libraries, which can be on separate computers.
• SCVMM SQL Server stores information about the stored and running virtual machines.
• SCVMM console is the administrator's user interface to SCVMM. You should install a console on the same machine as Team Foundation Server. You can also install consoles on other machines from which you want to control SCVMM. Additionally, you can install a Self-Service Portal for SCVMM, not shown here, which provides a web interface that allows non-admin users to create VMs.
• Team Foundation Server stores work items such as test cases, user stories, bugs, and developer tasks.
  • Team Foundation Server also provides version control for source code and other project artifacts.
  • For a big project, you can install instances of Team Foundation Server on separate machines and combine them into one logical cluster, which has a single URI for user access.
• Lab Manager allows you to create and manage lab environments, which are groups of virtual or physical machines on which you can run tests. Lab Manager is part of Team Foundation Server, and it provides features on top of SCVMM.
• Build Service performs continuous or regular builds on the server, taking its source code from Team Foundation Server source control. It communicates with a build agent in each test machine, allowing it to deploy compiled code into the machine.
• Test controller runs the script that performs a test. In each test machine, it works with a test agent to start the tests and collect data.

Client components – typically located on your desktop:

• Visual Studio is the principal interface to Team Foundation Server work items, source control, and build service.
• Microsoft Test Manager (MTM) is the interface to Lab Manager and the test controller.
• TFS Admin, the administrator's console of Team Foundation Server.

Lab Manager and virtualization

We deal with Lab Manager in more depth in Chapter 3, "Lab Environments." Let's take a moment to understand the relationship between Lab Manager and virtualization.

Lab Manager is a feature of Team Foundation Server. You enable it from the Team Foundation Server console. Users access Lab Manager from their desktop machines by using the Lab Center section of Microsoft Test Manager.

Lab Manager lets users create and control lab environments. A lab environment is a group of machines on which you can install a system that is to be tested. In particular, lab environments are designed for testing distributed systems such as web services.

A lab environment can be composed from physical or virtual machines. The big advantages of using virtual machines—which we strongly advocate in this book—are that users can create clean environments very quickly, and that an environment in which a bug has been found can be saved in that state for later investigation. To get these benefits, you have to install Microsoft System Center Virtual Machine Manager (SCVMM). SCVMM provides the facility of keeping virtual machines in libraries; Lab Manager lets you combine virtual machines into virtual environments in which all the machines in the environment can be stopped, started, and stored as a single entity.

Users can also create standard environments which can be composed of any machines. They can be physical or virtual, and if they are virtual, they don't need to be managed by SCVMM. Standard environments don't have all of the benefits of virtual environments, but they help you deploy and run tests. We recommend standard environments for some kinds of performance tests, but prefer virtual environments for most other cases.

You can set up Lab Manager without installing SCVMM or without installing Hyper-V. In that case, users can create only standard environments. This might be a useful scenario if the team has a lot of investment in testing frameworks based on physical machines or on third-party virtualization frameworks.

The virtual management framework

Example configurations

Now let's think about how we're going to spread the infrastructure components over different physical computers. Looking back at the diagram of components, we can draw different boundaries around them to assign the components to different boxes. As we've said, there are many arrangements that will work. Let's consider a few.

The non-starter setup

If we really want to economize, should we just put everything on one computer?

For example, perhaps we could pack all the infrastructure components into the same box, alongside Hyper-V. Well, it would work, and you can do it if you are really short of cash or space. But it is likely to perform badly in any serious project. Hyper-V is quite good at optimizing performance when all the resources are being used by VMs under its control; but it doesn't work so well if there are other services running alongside it, and taking up cycles at unpredictable times.

Another idea might be to run the infrastructure components in their own virtual machines in Hyper-V alongside the test machines. But this makes the machines containing Team Foundation Server and so on show up in the same list in SCVMM as your ephemeral test machines. Because you'll get used to creating and deleting test machines about as often as you break for refreshments, this arrangement carries the risk that you might delete your Team Foundation Server installation by mistake, thereby reducing your hard-won popularity with your colleagues.

We therefore recommend at least two computers.

The economy setup

In this setup, we put all the infrastructure on one computer, and Hyper-V for the Test VMs on another.

To really pare down the budget, we can omit SharePoint (or just use SharePoint Standard). To provide storage for Team Foundation Server, we could use SQL Server Express instead of SQL Server. However, these choices would mean we lose the project dashboards and online charts of the project's progress against tests.

The economy test setup: two computers

In this configuration, a typical procurement spec would be:

Test host:

• 16 effective CPUs (or more)
• 48GB RAM, 64-bit architecture
• Designed for Hyper-V (which is not true of all 64-bit servers)
• Windows Server 2008 R2 Enterprise 64 bit
• C: drive 100GB for Windows
• E: drive 2000GB for virtual machines

Infrastructure server computer:

• 4 or more effective CPUs
• 10GB RAM or more, 64-bit architecture
• Windows Server 2008 R2 Enterprise 64 bit
• C: drive 200GB for software
• E: drive as large as possible for VM Library

Software:

• 2 x Windows Server 2008 Enterprise R2 64 bit
• Team Foundation Server 2010
• System Center Virtual Machine Manager 2008 R2 SP1
• SQL Server Express (or SQL Server 2012 or 2008 Standard)
• (SharePoint Standard)

Desktop machines for developers:

• Windows 7 Professional or Enterprise
• Visual Studio Professional (or Premium or Ultimate)

Desktop machines for testers:

• Windows 7 Professional or Enterprise
• Visual Studio Test Professional (or Ultimate)

Separate server computers for high traffic

To scale up somewhat, let's buy another three computers. By moving components out to them, we intend to reduce the impact of sudden loads in one component on users of the others. The components we move out are:

• Build Service, which has high CPU and disk load during a build.
• Test controller, which collects large amounts of data during a test run.
• SCVMM, which transfers large amounts of data when saving or restoring a VM. It's best to keep it with its library and database.

Separate build, test, and virtual library controllers

Separate file server for the VM library

In the following configuration:

• The SharePoint server is separated out, allowing it to be used heavily as a project resource, independently of the Team Foundation Server instance.
• An additional VM library runs on its own box. Additional libraries can be in separate computers, though the initial library must always be on the same box as the SCVMM controller.

Separate SharePoint server and additional VM library

More computers

As your project grows, you might use more computers to:

• Create more test host computers. Each one will have Hyper-V and a VMM agent.
• Provide a full SQL Server installation for SCVMM, instead of using SQL Server Express. This improves performance if you have more than about 150 test machines.
• Create a Team Foundation Server cluster consisting of several Team Foundation Server instances.
• Create multiple build services and test controllers.

Server components on virtual machines

Lastly, it is possible to put all the framework components in one or more virtual machines. This makes it easy to replicate the whole setup in another project. In the following example, each virtual machine has its own (licensed) copy of Windows Server, along with one of the server components:

Framework components in virtual machines

This puts the server components all back into one physical computer. The only difference from our first configuration is that the components are in separate virtual machines. So what's the benefit of that?

Firstly, by putting, say, the Build Service into its own VM, you are limiting its ability to interfere with other processes; even when it is running at capacity, it can't use more CPUs or RAM than you have assigned to it, and thus cannot take power away from the SharePoint and Team Foundation Server instances that are responding to team members' queries.

Secondly, the separation provides a security barrier; a script running on the build server cannot do damage to the Team Foundation Server database.

Lastly, you can take snapshots of these virtual machines and replicate them when you want to set up a new project with its own servers.

For useful posters about configuring Team Foundation Server, download Visual Studio ALM Quick Reference Guidance.

Licensing

When you create virtual machines, you are creating a new copy of the Windows operating system, and also of anything else you installed on the virtual machine template. You must therefore consider how those items should be properly licensed.

Please refer to Windows Activation in Development and Test Environments:

To summarize the situation at the time of writing:

• Copies of Windows on virtual or physical test computers need not be activated unless you want to keep them for more than 30 days. It is also possible to extend the grace period to 120 days.
• Windows on other machines—whether physical or virtual—must be activated. This would include host servers and all infrastructure machines, such as the Team Foundation Server.
• If your organization has a Key Management Service (KMS) host, new instances of Windows on your network are automatically activated, using your organization's volume license. This is the simplest situation: if you don't have KMS, consider setting one up.

Service accounts

You will need to set up a number of service accounts in your organization's network. These accounts are used by server components to access each other and require domain access. You don't want to use personal accounts for this purpose, because you'll want to share the passwords between several administrators.

Service accounts should have no entry in your organization's email address list.

Make arrangements to update the password on a schedule. Updating a password means updating the places where the password has been entered, so that the test framework doesn't stop working.

When you are setting up most of the services, you need to have administrative permissions.

Many of the services that you need to set up have the option to run under the built-in Network Service account. Choose that where you can.

Here is a summary of services and the accounts required:

• Test Controller and agents
  • Mostly run under the built-in Network Service account.
  • To run coded UI tests (described in Chapter 5, "Automating System Tests"), the test agent has to be running as a desktop application with a user logged in. This user should be a service account.
• Build controller
  • Network Service account.
• Team Foundation Server
  • Most functions run under the built-in Network Service account.
  • Lab Management (VMM) runs as a service account.
• SQL Server
  • Network Service.
• SCVMM
  • The same service account as Lab Management.
• SharePoint
  • A separate service account.

Service account usage

The following diagram sets out the accounts that are used to access different parts of the testing framework. In this diagram, an arrow indicates that the node at the source end has to be in possession of credentials that can be used to access the target end.

Note

This diagram and the notes in this section might not make much sense until you have performed some of the installations. Come back to look at it later.

Service account dependencies

The dependencies depicted in the diagram are:

• The client machine runs under a user account. To access Team Foundation Server and its features, the user must be registered with the team project as a Contributor.
• Team Foundation Server Admin:
  • You provide this account on installation.
  • You need this account to connect Team Foundation Server Administrator Console to the Team Foundation Server.
  • You also provide it to the build controller and test controller when you register them with Team Foundation Server.
  • To manage the build controller, use Team Foundation Server Administrator Console and connect to the build controller machine.
  • To manage the test controller, use the test controller management tool, which you can install from the Team Foundation Server DVD.
• Lab Machine Admin:
  • You need to add the Lab Machine Admin account to the Administrators group in every lab machine (virtual or physical). It can be a local account on each machine, but must have the same password on every machine.
  • The Lab Management feature is controlled by opening Team Foundation Server Administrator Console. Connect to the team collection and open the Lab Manager page.
  • In Lab Manager console, choose Configure, Service Account and provide credentials of the Lab Machine Admin account.
  • When you set up lab machines, always add this same account to the Administrators group.
• SCVMM Admin:
  • SCVMM runs under a service account, which you provide.
  • SCVMM is controlled with the SCVMM console, which should be installed in the same machine as Team Foundation Server.
  • To connect to SCVMM from the console, you need the SCVMM service account password.
  • Add the Team Foundation Server service account to SCVMM Administrators group.
• Hyper-V Admin:
  • On each Hyper-V host computer, you must add the Hyper-V Admin account to the Administrators group.
  • You provide credentials of this account when you use the Add Host command in SCVMM console.
• Test agent for UI tests.
  • When you set up a new environment in Lab Center, you can configure one of the lab machines to run coded UI tests. You must provide an account under which to run the tests. Lab Center will configure the test agent on that machine to log into that account.

For more information about service accounts, see Service Accounts and Dependencies in Team Foundation Server. For Visual Studio 2010, see Accounts Required for Installation of Team Foundation Components.

Installing the software

OK, so at this point you have:

• Decided upon, bought, and powered up the physical hardware that you need.
• Decided which infrastructure components will go on each computer.
• The infrastructure products on DVDs (or downloaded the equivalent ISOs or installer files).
• Registered the service accounts in your corporate network.

Now, you might think that it's unnecessary for us to include here any long-winded advice about how to install some software. You are looking forward to a relaxing day of reading your favorite testing blogs while intermittently changing a DVD, clicking through an installer wizard, and mindlessly accepting obscure legal terms and conditions. Furthermore, there is plenty of help on the web of the "Step 43: Click OK" variety, should you feel the need to have your hand held through the process.

However, you might find that there are a few options presented by the installers that feel a bit like "Would you prefer to exist in a single infinite universe, or in a finite brane in an infinite multiverse? This choice cannot be undone, and is final and complete and forever, and must be made now." In addition, all the help about the different components are in different places, and are generally reluctant to acknowledge each other's existence.

We therefore feel it might be useful to offer a few observations and recommendations that are aimed specifically at integrating the components into a testing infrastructure.

Installation overview

Follow these steps to set up your test infrastructure. The ordering is important, because of dependencies between the parts:

1. Set up Hyper-V to provide a host computer for test virtual machines.
2. Set up computers for test infrastructure products.
3. Install System Center Virtual Machine Manager (SCVMM) for virtual environments.
4. Install SQL Server 2008 Standard for project management charts and reports showing burndown. (You could use SQL Express, but you would not get the most useful project progress reports.)
5. Install SharePoint for the project portal and reports on test progress.
6. Install Team Foundation Server:
   1. Configure the Build Service.
   2. Configure Lab Management.
7. Populate the virtual machine library with a base set of machines that will be used for tests. Users can replicate and modify the library contents, so the first step is just to provide machines that contain the principal operating systems that they are likely to use.

Hyper-V

Configure Hyper-V on your test host computer. If you have decided to run your infrastructure components in virtual machines, you will also want to install Hyper-V on a separate computer.

A machine on which you want to install Hyper-V should have: 64-bit architecture; hardware-assisted virtualization; Windows Server (we use 2008 R2); at least one very big disk; lots of RAM; and many logical CPUs. It must be a physical computer. We recommend you don't use any other role. (See Install the Hyper-V Role on a Server Core Installation of Windows Server 2008 on MSDN.

To configure Hyper-V:

1. Make sure the computer is joined to your network domain.

   1. In the System control panel, look under Computer Name.
   2. Choose a name for this computer that ends in "-HOST". This helps avoid confusion between virtual and physical machines.

2. In Server Manager, choose Roles, Add Roles, Hyper-V.

   

   Enabling Hyper-V

3. Set the default storage locations to this computer's very big disk:

   1. In Hyper-V Manager, select this computer and choose Hyper-V Options.
   2. On the Virtual Hard Disks page, enter a folder such as D:\VHD.
   3. On the Virtual Machines page, enter a folder such as D:\VM\.

Virtual machines for test infrastructure components

This section is about installing test infrastructure products (Team Foundation Server and so on) on virtual machines. If you're going to install those products on bare metal, skip this section.

Note

This section isn't about creating the virtual machines you will use for testing. Once SCVMM is running, you will use that to set up test VMs. We'll discuss that later.

There are two methods for setting up virtual machines:

• Install Windows from a PXE server, installer disk, or ISO file, as you would with a physical computer (see Walkthrough: Deploy an Image by Using PXE; or
• Replicate an existing VM that already has Windows installed.

Your first virtual machine: installing Windows on a new blank VM (60 minutes)

1. Create the VM. In Hyper-V Manager, choose Action, New, Virtual Machine.
   Enter these choices:

   • Specify Name and Location:
     • Name: Use the same name as you will use for the domain name.
     • Store: Make sure it is on the big disk drive.
   • Configure Networking: choose Local Area Connection – Virtual Network.
   • Connect Virtual Hard Disk:
     • Location should be on the big disk drive, for example D:\VM\.
     • You can add more hard disks later.
   • Installation options: If your organization has a PXE server, choose Install an operating system from a network-based installation server. Otherwise, select your Windows DVD or .ISO file, which you should make available to the host machine.
   • When you finish the wizard, the VM will appear in the list of machines, in the Off state.

2. Start the VM and choose Connect. The VM's console screen will appear.

   If you selected a network installation, you might need to press F12 to choose the operating system.

   Windows will be installed. When asked, provide an Administrator password.

   If your network doesn't have KMS, you'll also have to provide a Windows activation key. (See the Volume Activation topic on TechNet.)

3. Log into the console. To log into a machine in Hyper-V, choose Connect to open its console window, and then choose the CTRL+ALT+DEL button at the top left of the console window.

   

   Logging in

4. Perform housekeeping:

   1. Get updates. In the Windows Update control panel of the VM, set updates to Automatic. You will typically have to restart to complete the updates.
   2. Enable Remote Desktop.

5. Add processors and disks:

   1. Shut down the virtual machine.

   2. In the Hyper-V console, select the VM and choose Settings.

      

      Virtual machine settings

   3. On the BIOS tab, move IDE to the top of the Startup order list. This prevents the VM from trying to start from PXE in the future.

   4. On the Processor tab, adjust the number of logical (= virtual) processors.

   5. On the SCSI Controller tab, you can add extra virtual hard drives.

      Specify a fixed-size disk. Don't forget to set its location on the big disk of the host.

   6. Remove the Legacy Network Adapter.

      Choose Add Hardware, and then Network Adapter. This type of adapter runs more efficiently.

   7. Save the settings and start the VM.

   8. If you added a disk, you will need to mount it in the VM: Choose Administrative Tools, Computer Management, Storage, Disk Management. Select the new disk and Initialize it. Then create a New Simple Volume on it.

6. Export the VM so that you can use it as a template to create new virtual machines:

   1. Install any additional software that you want to be replicated to every copy.
   2. Shut down the VM.
   3. In Hyper-V Manager, select the VM and choose Export. Export to a separate folder on the big disk such as D:\exports\.
      The export operation can take 5-20 minutes, and runs in the background. You'll know it has finished when the Cancel Exporting command disappears.

7. Delete the VM. You are going to use the exported version as a template from which to create copies. Deleting the original helps you avoid name clashes when the copies are started.

   1. Delete the VM in Hyper-V.
   2. Delete the disk files on the host in D:\VHD\.

More virtual machines: creating a virtual machine by import (15 minutes)

Make sure the original VM— from which you exported—is paused or shut down before you create a VM by import. The new VM will have the same domain name as the one from which it is copied. You must therefore change the domain name before you can have both machines running.

1. In Hyper-V Manager, choose Import Virtual Machine.

2. Select these options in the wizard:

   • Copy the virtual machine (create a new unique ID).
   • Duplicate all files so the same virtual machine can be imported again.

   The operation typically takes 3-10 minutes.

3. Rename the new machine in Hyper-V. This changes only the name by which it is identified in Hyper-V.

4. In D:\VHD, rename the new computer's virtual disk files:

   

   Virtual hard disk names

5. In Hyper-V, open the Settings of the new machine, and edit the definition of each disk. Change the location of the disk to point to the new virtual disk file names.

   

   Change location

6. Start the new VM and log into it.

7. Join the computer to a domain by using the System control panel of the VM. Restart the machine.
   Make the computer's domain name the same as its name in Hyper-V; this isn't automatically the case.

8. Add users to the Administrators group. Choose Administrative Tools, Computer Management, Local users and groups, Groups, Administrators and add aliases to the group. Don't forget yourself.
   From this point, you can log into the VM by using Remote Desktop.

Install System Center Virtual Machine Manager (SCVMM)

SCVMM lets you keep a library of virtual machines. It also allows a whole set of Hyper-V hosts to be treated as though they were a single pooled resource. SCVMM is a pretty powerful tool, allowing you to create your own local cloud. It can even move VMs between one server and another while they're working to optimize performance.

We'll use SCVMM to supervise test VMs.

Prerequisites:

An account on your domain: the VMM Service Account.

A domain-joined physical or virtual x64 machine with Windows Server 2008 R2 SP1.
This can be the same computer as a Hyper-V test host.

A large disk on which to store the VM library.

The installation DVD and product registration key for System Center Virtual Machine Manager 2008 R2.

Install the VMM server

1. Using Remote Desktop, log into the virtual or physical machine on which you plan to install SCVMM.
2. Start the SCVMM installer, and then choose to set up VMM Server.
3. When the wizard asks whether to install SQL Server Express, say yes. (But if you plan to run more than 150 hosts for test virtual machines, say no, and install SQL Server 2008 on a separate machine.)
4. The Library Share should be on the large disk. You can add another share on another machine later if required.
5. Change the default VMM communication port from 80 to another value such as 8000. This leaves port 80 free so that you can install SharePoint or the Self-Service Portal on this machine.
6. Provide the VMM Service Account.

Install other bits

Use the same installer disk or ISO to install the following pieces:

Component	Where	What for
VMM administrator console	VMM server machine	Aids administration.
	Team Foundation Server machine	Enables lab management.
	Your desktop	Aids administration.
VMM local agent	Test Host Hyper-V computers; but the VMM server will normally install this for you.	Allows SCVMM to control hosts.
VMM self-service portal	VMM server machine	Allows users to create VMs.

When you install the VMM Self-Service Portal, you need to:

• Configure it to use a port other than 80; or
• Place it on a separate machine from SharePoint

Connect to Hyper-V

In the SCVMM console, use the Add Host command, and provide credentials for a service account that has administrator permissions on the Test Host box. SCVMM will add this service account to the Virtual Machine Manager security group on the host machine. It will be used to control the SCVMM agent.

Registering a Hyper-V host with SCVMM

This will install the VMM agent on the Hyper-V computer, and start the Hyper-V role if necessary. It can take a few minutes.

Enable Microsoft .NET 3.5 and Internet Information Services (IIS)

In Server Manager, open Features, and enable .NET 3.5

In Server Manager, open Roles, and add Web Server (IIS). Enable its role services:

• Common HTTP Features
• Application Development
• Management Tools\IIS Management Console

See How to: Configure Team Foundation Server By Using the Standard Configuration for Single-Server Installations on MSDN.

Install SQL Server 2012 or 2008 R2 for Team Foundation Server

You have to install SQL Server 2012 or 2008 R2 if you want project management charts and reports showing historical data such as burndown. We recommend this. (If you don't install one of these versions at this point, the Team Foundation Server basic installer will install SQL Server Express instead.)

1. In the SQL Server installer, select the following features:

   • Database Engine Services\Full-Text Search
   • Reporting Services (each variant)
   • Integration Services

2. On the Instance Configuration page, set Default instance.

   (If you set any other instance name, you will have to use Advanced setup in Team Foundation Server, and refer to the database as machineName\instanceName.)

3. On the Server Configuration page:

   • Provide your SQL Server service account credentials. Click Use the same account for all.
   • Set the Startup type of SQL Server Agent to Automatic.

4. On the Database Engine Configuration page:

   • Choose Add Current User.
   • Add your Team Foundation Server service account.

5. On Reporting Services Configuration

   • Choose Integrated Mode if you will be installing SharePoint.
   • Choose Native otherwise.

Enable TCP and Pipes protocols

When the installation is complete, open SQL Server Configuration Manager.

Open SQL Server Network Configuration/Protocols for MSSQLSERVER. Make sure that the Named Pipes and TCP/IP options are enabled. If you have to change them, open the SQL Server Services page and stop and restart the SQL Server service.

Install SharePoint (if required)

You can skip this step if you don’t expect to make heavy use of SharePoint. The standard installer for Team Foundation Server includes an installation of SharePoint.

SharePoint provides an enhanced project website, including dashboards that show collections of reports on the project’s progress. It also provides a project portal where you can post announcements and share documents. (See Manually Installing SharePoint Products for Team Foundation Server on MSDN.) If you expect only to use the dashboards and share a small number of documents, skip this step.

However, if your team will make serious use of SharePoint, we recommend that you install it on a separate machine from Team Foundation Server. It works best on a machine with at least 8GB RAM.

You might also install SharePoint now if you want to use the more advanced installer for Team Foundation Server, which does not include SharePoint installation; or if you want to install SharePoint Enterprise. By using the advanced Team Foundation installer, you can also integrate it with an existing SharePoint site.

Once you have installed SharePoint, test it with your web browser: https://servername/.

To administer SharePoint, note the URI provided by the installer; for example, https://servername:17012.

Install Team Foundation Server

Run the Team Foundation Server installer from the DVD. It installs and configures prerequisites such as .NET Framework 4.5, and might require you to restart the computer. If so, the installer will resume when you log in again.

Most of your choices are made in the Configuration Manager, which starts up when the installer is finished.

Configure Team Foundation Application Server

The initial choices in the configuration wizard are:

Standard Single Server – Choose this if you are installing SharePoint and SQL Server on the same machine as Team Foundation Server, and if your SQL Server database has the default name. If you have not already installed SharePoint, this wizard will install it for you.

Advanced – Typical reasons for using this are:

• Your SQL Server or SharePoint Server installations are on separate machines.
• You gave your SQL Server a name other than the default, in which case you'll have to enter it as machineName\serverInstanceName.
• You want to set up a cluster of Team Foundation Server machines that will function as a single large-scale service.
• Any of the assumptions made by the Standard Single Server wizard about how you've set up the rest of your kit turn out to be incorrect.

Basic – This doesn't give you reporting or a SharePoint portal. But you probably want both of these, because you want to be able to see charts that show how many tests are passing for each of your user stories.

Enter your Team Foundation Server service account in the wizard. Note that the Test button checks only that the credentials are valid in the domain; it doesn't check that all the relevant services can be accessed.

When the configuration has finished, note the connection details:

Completed configuration

The Web Access URI can be used from a web browser.

The Team Foundation Server URI is entered into Visual Studio or Microsoft Test Manager in the Connect to Server dialog.

Set up Lab Management

1. Start Team Foundation Server Administrator Console.
2. Expand Application Tier, Lab Management.
3. Choose Configure Lab Management.
4. If prompted, provide your own account (or an Admin account on the SCVMM machine).
   In the wizard, the default Network Isolation and Advanced settings are OK.

Create a team project collection

In the Team Foundation Server Administrator Console, in Team Project Collections, choose Create Collection.

1. On the Data Tier page, give the machine the name of the SQL Server 2008 instance. Unless you created a separate SQL Server instance for Team Foundation Server, this will just be the local machine name. Choose Create a new database.
2. On the SharePoint Site page, Team Foundation Server will create a SharePoint sub-site as this project collection's portal. In the Web application, you need the web address of the SharePoint site; if you put everything on the same machine, it will just be http://thisMachine.
   Make a note of the URLs of the project portal sites.
3. On the Reports page, Team Foundation Server will set up a SharePoint sub-site on which you can view generated reports. Make a note of the URLs.

Set up the build service

You can set up the build service on the same machine where Team Foundation Server is installed, or on a different machine. Using a separate machine avoids any sudden slowdowns in Team Foundation Server when a build starts. (See Scenario: Installing Team Foundation Build Service on MSDN.)

Note

Don't forget to install any platform software on the build server so that your built software can run on it. For example, if you are developing software that uses .NET and SQL Server, install the correct versions of each product.

Install the build service from the same DVD or ISO (disk image) as Team Foundation Server.

In the Team Foundation Server Administrator Console on the build service machine, select Build Configuration, and choose Configure Team Foundation Build Service. The main item to choose is the path of the Team Foundation Server project collection; the default settings usually work for everything else.

The wizard sets up a build controller and agents.

If you set up the first team project collection after you start the build service, you will have to come back to the Build Configuration console. Open Properties to connect the service to a team project collection. You can then use the New Controller and New Agent commands, choosing default values for everything.

Build configuration

Build service properties

Allowing build completion emails

Open Team Foundation Server Administrator Console, and under your server machine name, select Application Tier.

Make sure that Service Account is set to an account that has permission on your domain to send email messages. If it isn't, use Change Account. Don't use your own account name because you will change your password from time to time. (If you ever have to change the password on the service account, notice that there's an Update Password command. This doesn't change the password on that account; it changes the password that Team Foundation Server presents when it tries to use that account.)

Setting the email notification account

Scroll down to Email Alert Settings and choose Alert Settings. At this point, you'll need the address of an SMTP server in your company's network. Get one from your domain administrator.

Email alert settings

Connect to Team Foundation Server in Visual Studio

From your desktop computer, you should now be able to connect to Team Foundation Server:

Connecting to your server in Visual Studio

Create a project in the new collection. In Team Explorer, choose New Team Project on the shortcut menu of the team collection.

New team project

Add team members

You can control access by individuals and by teams. Typically you create a team in Team Foundation, and then set the permissions of the team. Individuals can be added or removed from the team.

In Visual Studio, choose Team, Team Project Settings, Group Membership. Add people in your team to the default team. Also consider adding individuals to the Project Administrators group.

Connect in MTM

Connect to your project from Microsoft Test Manager:

Connecting to your project in MTM

Set up a test controller

A test controller is used to coordinate the deployment, running, and monitoring of tests on remote machines. If you want to run tests on any machine except the one where you built the software, you need a test controller. In particular, you need a test controller to run tests of client/server or other distributed systems.

One place to set up a test controller is on any machine—for example, your own desktop—from which you want to coordinate tests. In this case, you use Visual Studio as the user interface to the test controller.

Alternatively, you can register a controller with a team project collection. You need to do this if you want to run on test environments. You can install one test controller on any computer. The easiest location is the same machine on which the team project collection is located.

In your Team Foundation Server installation pack, find and run the installer for test controllers. You might also be able to find an ISO file that can be downloaded from the web by searching on "Visual Studio Agents."

To install from an ISO file onto a virtual machine:

1. Copy the ISO file to the Hyper-V computer that hosts the virtual machine on which you want to install the controller.
2. Use Hyper-V to pause the installation machine. Open its settings and on the DVD page, mount the ISO file on the installation machine's virtual DVD drive.
3. Resume the installation machine.
4. Log into that machine and install the test controller from the DVD.

When the installation has finished, check the Configure Now box.

If you are creating the test controller to run test cases from Microsoft Test Manager, configure the test controller as a Network Service, and register it with one of your Team Foundation Server collections.

Alternatively, if you are creating a standalone test controller to run through Visual Studio, set it up on your Visual Studio machine. Both the test controller itself and the test controller management tool are installed. (In Visual Studio 2010, use the Manage Test Controller item on the Test menu.)

Setting up physical and virtual machines for testing

You've now set up the basic testing infrastructure. One thing remains to be done, which is to populate your library with virtual machine templates that you can use for testing. You might also want to configure some physical machines for testing.

Typically you'll set up two or three virtual machines with different operating systems from scratch, and after that you can create the others by making copies in which you adjust the configurations.

You are likely to need at least four templates:

• Test lab servers. These are machines on which a tester will typically install the server part of a client/server system.
• Manual testing client. Testers will use this template to test web clients or desktop applications. See Chapter 4, "Manual System Tests." It includes:
  • Web browsers – several makes and models, if you are testing a web application.
  • Visual Studio Test Professional. This provides you with the Test Runner, which helps a tester work through the tests and can record and play back their actions.
• Automated test development client. VMs created from this template are used to debug automated tests. See Chapter 5, "Automating System Tests." It includes:
  • Web browsers.
  • Visual Studio Ultimate.
• Domain Controller. This VM is used to provide a domain name server in a network-isolated environment. For more information, see Working with Network Isolated Environments in Chapter 3, "Lab Environments."

Creating a virtual machine by using SCVMM

The first virtual machines in your library have to be created by using SCVMM. You can then store them in the SCVMM library, and import them into Lab Manager. From there, users can adapt the initial virtual machines and store new versions in the library.

Tip

Configure the SCVMM Self-Service website. This allows team members to create new virtual machines without having administrative privileges on the SCVMM server.

Follow the instructions in the MSDN Topic: How To: Create and Store virtual machines and templates ready for Lab Management. In summary the process is as follows:

• Create a new virtual machine and install Windows. If your organization has a PXE server, it makes the installation easier.
• Add a user account that has Administrator privileges and is the same on every lab machine. This allows Lab Manager to administer the machine.
• Install a test agent from the Team Foundation Server DVD; but, do not connect it to a test controller yet. (Lab Manager will do this when you use the machine in a lab environment.)
• Configure Windows on this machine as you will want it on machines that are created from this template. For example, you might want to enable the Web Server (IIS) role.
• Install whatever other software you want to exist on machines created from this template; for example, Visual Studio.
• Clear the Administrator password and the local password policy. These are special requirements for saving the machine as a template.
• Shut down the machine.
• In the SCVMM console, store the machine in the library as a template.

Where to go for more information

There are a number of resources listed in text throughout the book. These resources will provide additional background, bring you up to speed on various technologies, and so forth. For your convenience, there is a bibliography online that contains all the links so that these resources are just a click away.

Next Topic | Previous Topic | Home | Community

Last built: Aug 6, 2012