Friday, 28 August 2015

Draft Builds in the new Team Build

With the new Team Build you have the possibility of working on Build Definitions in an asynchronous fashion, without impacting other team members or wasting time cloning the existing build.

For example, you might want to add some tasks to an existing Build Definition – you can then Save as a draft..


You are actually creating a clone of the existing Build Definition with the new steps you added. You can even run it!


All the builds you run with this definition are marked with a .DRAFT in the name:


This is not different compared to any other build – it is just not affecting the existing published builds:

image image

Then once you save it everything is merged with the original definition, with no further effort.

Tuesday, 25 August 2015

Quickly change the TFS Integration Platform settings

You installed the TFS Integration Platform, and now you want to move your database. Or you want to change the temporary folder used during the migrations.

Shall you waste time reinstalling it?

No, what you need to do is to modify some strings in the MigrationToolServers.config file:


Thursday, 13 August 2015

Pre-upgrading a large Team Project Collection to TFS 2015

TFS 2015 is out and we all rush upgrading our Team Project Collections!

But if you have a collection bigger than 1TB you should stand back and read some documentation before that. This page in particular explains what you should do if you want to upgrade such a huge collection.

The reason for using TfsPreUpgrade is very simple – you don’t want your users stuck for days while you upgrade Team Foundation Server. So the tool is going to partially upgrade the schema while the server is still available, so the actual upgrade (the one done by the installer) takes no longer than two days, which means a weekend, which also means no perceivable service interruptions.

You can run TfsPreUpgrade from whatever machine you like. In my testing environment I am using at the moment I am running it from a plain Virtual Machine which is going to be used by the Application Tier, but it has nothing installed yet. You basically need access to SQL Server, and that’s it.

First thing, run it with the Estimate switch. It will give you an idea of the time and space needed for the upgrade:


To give some context, this is data for a 2TB Collection. A few hiccups while running the Run switch might happen, especially with a temporary test environment:


but you can just relaunch TfsPreUpgrade and it would start again from the same failed point after a quick check. It is smart enough to not further expand your databases if you don’t need it:


Once it is done your offline upgrade will be much faster, because these operations were carried in advance!

Tuesday, 4 August 2015

Change the Release Management URL when the console is stuck

Quick one, but helpful IMHO. After updating Release Management Server or Client you might experience this:


and then you would be stuckyou can’t change the Release Management Server URL.

The quick and dirty solution would be changing the URL in the Microsoft.TeamFoundation.Release.Data.dll.config file.

A better solution is to run this command line tool, which basically automates the former. In the worst scenario, reinstall the Client and it would prompt asking for a Release Management Server URL.

Monday, 27 July 2015

Team Project rename: is it that easy?

Renaming a Team Project was the most asked feature for Team Foundation Server since 2005, with over six thousands votes on it. Microsoft finally delivered that feature in April, in Visual Studio Online first and then in Team Foundation Server 2015.

Why did it take so long?

Team Foundation Server relies on a set of SQL Server databases, with a quite…complex schema. It wasn’t just about detecting a certain name and replacing it, it is all about GUIDs and the likes. A lot of work was done on the architecture, and more of it client-side.

Client-side? Yes.

When you rename a Team Project in either Visual Studio Online or Team Foundation Server, what happens among the operations is that also you are also creating a redirect from the old Team Project to the same, renamed one.

Take a look:


this Foo Team Project has some work in it:


a query with an explicit value in it (Foo instead of the @Project macro):


and of course some code.

You can then rename it:


and what you’ll need to do is to care about code mappings (workspaces or remotes, this would be best handled by a client update – 2015, 2013.5 or 2012.5). Code is migrated, Builds are migrated, and all the Work Item Tracking migration is completely effortless.

So you say yes, and the Team Project is renamed. Teams with ‘Foo’ in their name are migrated too:


Areas and iterations are migrated too, as expected:


Even the explicit query is migrated!


So what happens if you go straight to Foo?




This doesn’t mean you are going to lose the possibility of using the former name – if you will reuse it, you would just lose the URL redirect but all the renamed artefacts would be kept as-is..

There are a couple of things you need to manually address after this. As mentioned above, you need to sort out the Workspaces or the Git Remotes, depending on the Version Control System you are using.

If you are using a BDT Build Definition with Lab Management, you need to refresh the Build Definition by running the wizard again so it can be properly linked again with the right Team Project. This is actually a workaround which will be solved by the new TFS 2015 Legacy Build Controller, but if you need to use older Controllers that’s how to sort it out.

On-premises, run a ProcessWarehouse job and a ProcessAnalysisDatabase job as soon as possible, so you will avoid any stale data in SSRS and the Excel Services in SharePoint would be already updated with the current names. The jobs would run anyway in the time interval you set, but this will avoid any temporary inconsistency in the reporting data.

Eventually, clear the SharePoint cache and run a SharePoint timer job so the Excel Services are up and running on the right values.

Friday, 17 July 2015

TFS and HTTP status 417

Panic today – a guy couldn’t connect to Team Foundation Server with a weird “The request failed with HTTP status 417: Expectation failed.

What did it happen? I never saw such a HTTP status code!

A bit of investigation explained the reason for it – the proxy he is using doesn’t support the expect100Continue behaviour, dropping the connection.

The guy used a proxy server indeed and he did not check the “Bypass proxy server for local addresses” checkbox. After checking that, he was able to connect to Team Foundation Server like everybody else.

It is also worth mentioning that this can impact also components like the Extension Manager, and you can bypass that setting by adding a node in the devenv.exe.config file - <servicePointManager expect100Continue="false"/>

Monday, 13 July 2015

How to configure SCVMM-based Lab Management for selected Team Projects

Not all the Team Projects we have in the company might need to get Lab Management, and we pretty much know about the need of locking down certain resources.

So if you want to enable SCVMM-based Lab Management you need to configure the Library Share and the Host Group on a case-by-case basis instead of dropping them all in, by un-checking the Auto-Provisioning checkbox here:


Then you need to run TFSLabConfig TPLibraryShare /add and TPHostGroup /add to enable the single Team Project.