Friday, 3 July 2015

How easy is to use a Symbol Server with Team Build vNext?

Answer: it is extremely easy!

A Symbol Server is a very important piece of infrastructure every development team should have. It enables someone debugging (with the aid of an IntelliTrace file for example) problems happened in production, relating them with the right version of the code deployed.

To use a Symbol Server with the new Team Build, you need to have a local build machine, and a file share. That’s it.

Download the agent, and expand it in a folder – say C:\agent:



Once done, launch ConfigureAgent.ps1


A command line wizard will start. Most of the times you only need to enter the relevant Visual Studio Online account or Team Foundation Server URL. If you want to run it as a service the default would be with LOCAL SERVICE, but you can obviously use whatever account you need.


Now you have a Build Agent on the Default Pool:


Create a build, and you will have the Index Sources & Publish Symbols activity already part of it. Then you only need to enter the file share you want to use for the Symbols Server, and launch a new Build.



What is this all about? If you browse the file share you will have all your PDBs indexed.


Then you can hook it to Visual Studio, so whenever you open an IntelliTrace file, or whatever other dump you can get from a production crash, it will point to the right version referred in the source of the crash itself.

Tuesday, 23 June 2015

Scrum meets the pool – swimlanes in VSO’s backlog board

With the update of June 3rd VSO got a new and very useful feature in the Backlog Board: swimlanes.

What does that mean? It means you can have this situation:


This allows for an even finer time and resources management, for example. It mostly impacts prioritisation, something that happens with critical bugs stopping a production system. Keep in mind that a swimlane configured as above should be used very sparingly.

It could be even more creative:


You might be selling a product which, from time to time, has customer’s personalisations, which you need to schedule with the product itself. This is another way of using the swimlanes.

It is a tool which increases the flexibility a lot – but remember that it is just an aid, it doesn’t work as a given. Your process must be already resilient to this, and the tools is only there to help.

Tuesday, 16 June 2015

Beware of the Package Location in VSRM!

I am working on a few scenarios using VSRM and DSC, and something funny happened. Picking a build up for release, I noticed this:


Localhost? I am pretty sure I didn’t enter localhost anywhere in VSRM!

And I was right – there was no localhost to be found in my pipeline configuration. But this just caused problems deploying to a different workgroup target server, due to the lack of a proper DNS infrastructure.

The culprit here is the XAML Build I was using, its Drop Location was configured with \\localhost because it is an AIO demo box, and as there is no such name resolution facility VSRM cannot access my source server from the target.

To fix this you’d just need to change the Drop Location of the build.

Wednesday, 3 June 2015

A note on reusing your custom fields

When you customise your Work Item Types you often start with a lone custom Field, and then you forget about it for a while.


But what happens when you need to add the same field to another WIT? The first thing you are naturally inclined to do is to add a new one, with the same name and reporting design but with a different Reference Name (because maybe you attended one of my sessions on TFS Administration and you then discover you should mark your custom Reference Names in a significant matter :-) ).

The result?


How can I reuse my existing field then? The easiest way is to create the custom Field in the second Work Item Type with exactly the same properties, including the Reference Name. So TFS will correctly use the same Field and your experience is going to be consistent.

Sunday, 17 May 2015

A design consideration: SQL Server AlwaysOn Availability Mode for TFS

There are a few bits of any Team Foundation Server deployment which are either taken for granted, or completely ignored. One of them is:

Why shall I choose a Synchronous-Commit Availability Mode for the TFS Data Tier using SQL Server AlwaysOn?

If you are running an AlwaysOn Availability Group, you should know that you have a choice on how to write your Transaction Log – hence your database integrity. My suggestion is to run Team Foundation Server’s data tier in a Synchronous-Commit Availability Mode.

The reason is very simple: TFS relies heavily on the Transaction Log, and it is the only way to guarantee a point-in-time recovery. Moreover, if you run AlwaysOn you cannot have any database in the Availability Group set without the Full recovery mode.

So you must use the Transaction Log, and it is critical for the Team Foundation Server recovery – using the Synchronous-Commit mode ensures that each Secondary Replica in your Availability Group has an updated copy of the Transaction Log, synchronised at the same time as the Primary Replica, for immediate failover and service continuity.

You will face a really minor increase in the RTO (a few seconds, generally) and a performance loss, but we are talking about something you won’t be able to realise in general usage, and you are ensuring your service has an excellent reliability.

Friday, 8 May 2015

A design consideration: Reporting Services on the Application Tier

There are a few bits of any Team Foundation Server deployment which are either taken for granted, or completely ignored. One of them is:

Why shall I install SQL Server Reporting Services on the Application Tier?

Fair question, if you are not considering installing it on a separate box – a different approach, usually not as common as the former.

The idea is to centralise all the client-originated HTTP traffic on a single endpoint. The endpoint of course can be a cluster address where you have multiple SSRS servers and Application Tiers, but the concept is the same. Centralise your traffic, possibly using DNS names. The documentation suggest that too:


so that the data tier is exactly that: the storage for Team Foundation Server’s (and related, if you want) databases.

Beware: it is not wrong to install it on the data tier (it is actually supported since Team Foundation Server 2008), but it is a matter of best practices.

Thursday, 7 May 2015

TF30170 errors and the TFS Cache

Weird things happen, like this:


An item with the same key has already been added.How?!

Nothing catastrophic actually – it is just a matter of clearing the cache. This happened because this instance of Team Foundation Server was restored as part of a Disaster Recovery exercise, and its ID was not changed.

So, in order to solve this (and other similar TF30170 errors) just look at the logs – if you find that explanation message in one of the exceptions, or similar (like “cannot add LinkTypes relationship”) then I would suggest to clear the Team Foundation Cache:

<OSDrive>:\Users\<youruser>\AppData\Local\Microsoft\Team Foundation\

There are some folders in there, each containing a Cache folder. Empty those Cache folders, and try again. If there is nothing actually wrong underneath the Team Project would be created without problems.

A couple of remarks: it happens that the Team Project would be actually allocated on your target server even if the creation fails (it won’t be accessible and it is shown as Deleting). In this scenario it is pretty common that Visual Studio launches part of the temporary Team Project deletion but it would fail because it is not pointing at the right server GUID – open the TFS Admin Console and relaunch a manual deletion on the temporary Team Project.

Eventually, this might happen because you are not marking your Transaction Logs backups, so you restored some of the database out of the right order. Please use the TFS Backup Tool, or if you can’t, mark the transactions so you won’t hit that again.