How to configure Visual Studio Team Lab Management 2013, once and for all

Every time I go at a conference/user group and Lab Management is mentioned I hear someone saying “Lab Management? I never understood how it sticks together…” “Wow, it must be an adventure to set it up!” and so on…

Well, after all Visual Studio Team Lab Management (yes, fancy name) is not rocket science at all! It is just a clever mix of many different components, each doing a different thing, to enable the “Virtual Test Fabric” scenario. Nothing more, nothing less.

To begin with, you would need System Center Virtual Machine Manager (2012 R2), at least one Hyper-V host, Team Foundation Server (2013.4 in this case), a Build Controller and a Test Controller.

Assuming SCVMM installed  and configured (how: install SQL Server Database Engine, install SCVMM pointing at it, add an Hyper-V host), you need to install the SCVMM Console on the Team Foundation Server Application Tier. Now you can configure Lab Management!

You just need to enter your SCVMM FQDN:

and – if you wish to use it – an IP Block and a DNS Suffix for your Network Isolated machines:

This is the core, infrastructure configuration. You are going to see that something is missing though…

You just configured the infrastructure for the whole Lab Management deployment, what’s missing is the configuration for each Team Project Collection you want to enable.

The two settings you need are:

• A Library Share (a normal SMB share) containing the SCVMM templates used by VSTLM to create your VMs
• A Host Group (it’s actually optional, as SCVMM creates a default “All Hosts” Host Group, which in your case is enough as we are assuming you are starting with one Hyper-V host server)
   

As mentioned, the Auto Provision flag enables all the Team Projects contained into your Collection.

Now the only missing piece is a Test Controller to bind to Lab Management. In fact, if you launch Test Manager and try to create a new Environment, it would complain:

So, let’s install the Test Controller and configure it:

If you need it, configure a Lab Service Account as well. This is helpful in cases where you need to resort to Shadow Accounts (or you can’t add the Service Account to the Local Administrators group), but let’s keep it simple and skip it for now. Just keep that in mind:

That’s all! This is the whole Lab Management configuration! Is it still rocket science? In another post we are going to look at the environments’ configurations and at some useful tips from the real world.

Why can’t I delete a Test Plan with MTM and TFS 2013 Update 3?

Do you want to delete a Test Plan from MTM? Fair enough.

Unfortunately the documentation is a bit outdated here – a quick Google to find this, and it is about Visual Studio 2010. It would work – but only if you are connected to a Team Foundation Server without Update 3.

If instead you are running 2013.3+, you would be greeted with a message saying … “Deleting a test plan is not supported for current version of Team Foundation Server. Use witadmin tool 'destroywi' command to destroy test plan work item.”

It is not a bug, but it is by design instead - it is the only downside of the conversion to Work Item Types of the Test Suites and Test Plans.

Basically prior to Team Foundation Server 2013.3 they were ‘special artifacts’, meaning you wouldn’t be able to treat them like Work Items – including advanced querying, charting, etc.

The Update 3 converted the whole thing to plain Work Item Types, but this means you no longer get the special feature of deleting it via MTM, instead you should run witadmin destroywi from the Developer Command Line – which is the only way of doing so. That is because deleting a Work Item is not really something that happens every day, and if done in the wrong way (for example, truncating relationships in linked Work Items) it could lead to issues with the Work Item Store.

Visual Studio Lab Management and Auto Provisioning

Despite it is very handy, the Auto Provisioning feature of Lab Management can become a trouble pretty quickly. If enabled, every Team Project will be authorised to deploy VMs in the VSTLM hosts, a situation which – 99% of the times – becomes unmanageable.

It’s not a TFS problem, and it depends on how the users are used to work. But if your deployment is used (as it should be, to be fair) and considered ‘as a service’, then IMHO you need to limit the scope a little bit, otherwise your Hyper-V servers are going be clogged like Beijing at the rush hour…or the M25.

There is a pretty quick fix for this though – after you grant the permissions to the specific Team Project to use Lab Management, you need to use two TFSLabConfig (and not TFSConfig Lab) commands: tfslabconfig TPHostGroup and tfslabconfig TPLibraryShare.

After that, you are ready to go!