Monday, 17 November 2014

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 VMsimage
  • 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.

Sunday, 16 November 2014

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.

Wednesday, 5 November 2014

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!

Tuesday, 28 October 2014

Impact of the new Visual Studio Online European Region

With the latest update Microsoft addressed one of the most repeated requests about Visual Studio Online. It isn’t a specific feature or capability, but it is a EU-hosted region for it!

Up to yesterday, you did not have any choice on where your VSO data is hosted - the VSO tenants were only in Chicago, San Antonio and West Virginia.

It wasn’t a matter of performance or latency – I personally never had heavy problems unless a service-wide problem arised – but it was all about governance. If you are a EU-based company or anyway you have operations in the EU, you know data protection it is a pretty important matter.

We are not talking about Microsoft snooping into your source code and looking at your intellectual property, not at all, but depending on what you work on you might have strict regulatory policies to apply. In detail, if you have EU operations (which means even a single server running in the EU), the EU Data Protection Directive applies, and it is stricter than the US counterside, especially on when data leaves the EU.

Visual Studio Online is covered by the Safe Harbor since I recall its existence, a bilateral agreement between the US Federal Trade Commission and the European Commission providing reciprocal protection to personal and sensible data, but for certain businesses or countries it was just not enough. Germany is a good example, where its privacy laws are way stricter than the general EU umbrella.

Eventually, if you store your data – whatever it is – on a US hosted service, your data could be inspected by the US Law Enforcement agencies under the PATRIOT Act.

So, introducing a EU-hosted region (in Amsterdam, for completeness) means a lot in terms of governance, as all of your intellectual property hosted there is subject to the EU DPD as such, and that’s all.

What you will be lacking today is Application Insights – but it would reach the EU VSO in time for its General Availability.

Thursday, 23 October 2014

Can I host multiple Git repositories in Team Foundation Server?

Of course you can!

I am in the middle of a migration project, and the team I am helping with has several Git repositories (converted from other version control systems) to upload to their Team Project.

It isn’t extremely intuitive – you need to open the Control Panel for your Team Project (https://yourserver.domain.tld/yourcollection/yourteamproject/_admin/_versioncontrol)


and from there you can create a new repository.


That’s all!


When you’ll navigate to the newly created Git repository you will get the Getting Started page as well, which is very helpful for first-time users.

Thursday, 16 October 2014

Again on the logs: are errors in the logs going to stop an upgrade?

A quick but interesting question came out this week: “if I see an error in the Event Viewer of the Application Tier, is it going to break a TFS upgrade?”

Generally speaking – no. The errors you see in the Event Viewer are client-side logs reported to the server. You might see an error on a client not able to connect, another one because of a non-existent user or value in the Work Item query, or more critically an error because you cannot contact your data tier.

It is the data tier which contains all the meat. All the data is stored over there and, if you look at the Configuration logs after an upgrade, the big show is there.

Of course there is a correlation between the data tier’s schema and the application tier version – everything is handled by the same binaries.

Thursday, 9 October 2014

Logs, logs, logs…

Team Foundation Server is by no means an easy product – especially with large deployments. One of the most important aids in the daily maintenance is taking care of the logs, which are very descriptive.

Apart from the usual suspects (IIS, SharePoint, SQL Server, SCVMM) inside the Event Viewer you are going to find all the logs related to the TFS Services – these logs are especially invaluable when it’s time to troubleshoot a client issue, because they will contain exactly the error the user experienced plus many information about his environment (in particular which client triggered the error).

One example is an error like this:


“TF10158: The user or group name <group> contains unsupported characters, is empty, or too long" Once it is logged inside the Event Viewer I am going to get the error itself, plus who (the user account) and from which client (Visual Studio, a browser, MSTest, MTM, etc…) experienced that – guess what happens if you receive a question on such a group Smile

But what about setup or update logs? They are elsewhere – you are going to find the link into the TFS Administration Console.

What is amazing is their verbosity – did you ever try opening one of them?

They are pretty self-explanative, and when it comes to a version update you will find detailed information about every step the setup does. This explains many things…for instance, did you know that the 2013.3 update which enabled Test Suites and Test Plans customisation has much of its foundations in the Update 2 bits?