Calling scripts in RM2015 vNext style

I recently improved all of my powershell scripts for RM2015 vNext deployments by including a param() clause at the start of each script. Only to discover that when using PS/DSC actions in RM2015 (and 2013 for that matter) you cannot pass parameters! Quite frustrating as the main reason i did this improvement was because of Microsoft’s message at the end of their Release Management vNext Plans blog post

To maximize the chances of carrying your investments forward, we recommend that you write PS scripts to drive your deployments with the current versions of RM server

and the default/recommended way to work with powershell scripts using the PowerShell on Target Machines VSO agent task is to pass parameters. Sure, the VSO agent task has the advanced option “Sessions Variables” for backward compatability but I would really prefer to make my RM2015 solution forward compatible instead.

So how do I make my RM2015 scripts and release templates forward compatible? Turns out it is not that difficult to achieve. You’ll need a generic wrapper script and three variables in RM. Your wrapper script should look like this:

Invoke-Expression "$PSScriptRoot\$PowerShellScript $ScriptArguments"

Make sure your wrapper script is included in your build drop together with your other deployment scripts. Then add three global variables in RM2015.

  1. PSScriptPath – set the value to the “drop releative” path of your wrapper script. (If this path differ between components make this a component variable instead)
  2. PowerShellScript – do not set a value at the global level, we just want the variable to show up in the dropdown list for Custom configuration in our PS/DSC action.
  3. ScriptArguments – do no set a value at the global level, same reason.

And now, your PS/DSC actions can look like this:


which corresponds nicely with how it is done in the VSO agent task:


We are now forward compatible!

TFS and VSO guidance – Area path

Team and organizations that are new to TFS almost always struggle with how to structure their hierarchy for the Area Path field.  The documentation might seem straight forward: “Area paths allow you to group work items by team, product, or feature area”. However, most teams quickly discover that this is easier said than done.

First of all, do not use area path to track teams unless you have to (currently no other way to do it in VSO). I’ve explained why in a previous post.

Second, start small with broad areas and add more detail (child nodes) as needed. I’ve seen too many teams getting stuck on implementing a “complete” area path hierarchy thinking the field wont be useful unless they have it all in place. Most of the time that is a real waste of time, usually resulting in a way too detailed hierarchy where many nodes are never used. Use an agile approach instead and add detail where needed, when needed.

Third, keep a user centric view. A very common scenario is that the area path hierarchy is defined by the development team usually resulting in something relating to the software architecture. Unfortunately this is rarely useful to non-developers, e.g. Product owner, stakeholders, end users. Product features or workflows are usually more useful as it makes more sense to the non-developers (typically the ones creating new requirements and bugs) and for reporting purposes. One of the most interesting solutions I’ve seen, and personally feel makes a lot of sense, is to map the area path hierarchy to the user manual’s table of content.


This is the second post in a series where I will try to give you some solid guidance on TFS/VSO or point you towards existing solutions and recommendations.

Visual Studio 2015 ALM Virtual Machine

There is finally a new Brian Keller Virtual Machine (BK VM) available, only it is no longer Brian Keller who is in charge.

The new home of the VM is the Visual Studio ALM VM blog. For anyone who wants to learn more about Team Foundation Server (TFS) and Visual Studio ALM platform this is almost a mandatory download.

TFS and VSO guidance – Teams

I often get questions along the lines of “How do we do this in TFS?” It can be anything from setting up teams to choosing the best process template or how to structure a useful area path tree. My answer is always “Well, it depends…” because that is the truth. It really does depend on quite a lot of things. Fortunately, most of the time, you can change how you do things as you gather more and more experience from working with TFS in your organization. On the other hand, if you start out wrong it might require quite a lot of work to rectify that mistake. This realisation quickly turns the original question into “Ok, so how are we supposed to do this in TFS? Are there any recommendations or best practices? What does Microsoft say?”

Well, if you take a quick look at MSDN Library you will quickly realize that Microsoft actually has quite a lot to say. But over the years they have become less and less prescriptive. Which is good. Unless you are looking for some solid pointers… As far as recommendations and best practices goes these golden nuggets of information can sometimes be difficult to find.

So, this is the first post in a series where I will try to give you some solid guidance on TFS/VSO or point you towards existing solutions and recommendations. These posts will be based on my experience from working with TFS over the last 10 years.

Setting up Teams

What you need to know here is that the default way of setting up Teams in a Team Project is flawed. It works, but it is flawed and it will often cause grief down the road. Why? Because it uses the Area Path field to define your teams. This is not what the field was originally intended for. The Area Path field is intended to categorize work into product areas. The team is not a product area. Having multiple purposes for one field is bad design and this will quickly become apparent when you want two teams to work on the same product as you suddenly find yourself maintaining two identical area path structures in TFS, one for each team.

A much much better way to set up teams in TFS is to add a separate Team field, which is actually fully supported by Microsoft and opens up a hidden Team settings interface in WebAccess. It will require some customization of your TFS but it is definitely worth the effort.

Team field settings page

Unfortunately, for those of you who are using VSO it is currently not possible to do the necessary customizations in VSO. You’re stuck with the default. This might change in the near future though as VSO process customization is coming.

Migrate a TFS project to another process template.

Back in 2011, 4 years ago I wrote a blog post called “Manual upgrade a TFS project to a new Process template”. Since then I have got some questions and feedback and now it’s time for an updated version based on the latest process templates in TFS 2015, this time from Agile to Scrum.

  1. Start with downloading the process template you want to upgrade to, to disk with the process template manager, for example to D:\MyDownloadedTemplate

2. Backup your old work item types in the TFS project you want to upgrade in case you need to do a rollback. Use the process template editor in Team Foundation Power Tools or from a Visual Studio command prompt with Witadmin.exe.

MD “C:\Temp\MyWorkItemBackup”

CD C:\Temp\MyWorkItemBackup

witadmin.exe exportwitd /collection:http://MyTFS:8080/tfs/MyCollection /p:”Demo-Agile” /n:Bug /f:”Bug.xml”

witadmin.exe exportwitd /collection:http://MyTFS:8080/tfs/MyCollection /p:”Demo-Agile” /n:Task /f:”Task.xml”

witadmin.exe exportwitd /collection:http://MyTFS:8080/tfs/MyCollection /p:”Demo-Agile” /n:”User Story” /f:”UserStory.xml”

witadmin.exe exportwitd /collection:http://MyTFS:8080/tfs/MyCollection /p:”Demo-Agile” /n:Issue /f:”Issue.xml”

witadmin.exe exportwitd /collection:http://MyTFS:8080/tfs/MyCollection /p:”Demo-Agile” /n:”Test Case” /f:”TestCase.xml”

3. If you have custom fields, add them to the downloaded process template with the process template editor.

4. Some work item types have different names in Scrum and Agile; because of this you first have change the name in the new template to the name of the work item type in the old template, Impediment to Issue and Product Backlog Item to User Story.

5. Upload the Work Item types from the new template to your project with Witadmin.exe from the Visual Studio command prompt.

CD C:\MyDownloadedTemplate\Scrum\WorkItem Tracking\TypeDefinitions

Witadmin.exe importwitd /collection:http://MyTFS:8080/tfs/MyCollection /p:”Demo-Agile” /f:”ProductBacklogItem.xml”

witadmin.exe importwitd /collection:http://MyTFS:8080/tfs/MyCollection /p:”Demo-Agile” /f:”Task.xml”

witadmin.exe importwitd /collection:http://MyTFS:8080/tfs/MyCollection /p:”Demo-Agile” /f:”Bug.xml”

witadmin.exe importwitd /collection:http://MyTFS:8080/tfs/MyCollection /p:”Demo-Agile” /f:”TestCase.xml”

witadmin.exe importwitd /collection:http://MyTFS:8080/tfs/MyCollection /p:”Demo-Agile” /f:”CodeReviewRequest.xml”

witadmin.exe importwitd /collection:http://MyTFS:8080/tfs/MyCollection /p:”Demo-Agile” /f:”CodeReviewResponse.xml”

witadmin.exe importwitd /collection:http://MyTFS:8080/tfs/MyCollection /p:”Demo-Agile” /f:”FeedbackRequest.xml”

witadmin.exe importwitd /collection:http://MyTFS:8080/tfs/MyCollection /p:”Demo-Agile” /f:”FeedBackResponse.xml”

witadmin.exe importwitd /collection:http://MyTFS:8080/tfs/MyCollection /p:”Demo-Agile” /f:”SharedStep.xml”

witadmin.exe importwitd /collection:http://MyTFS:8080/tfs/MyCollection /p:”Demo-Agile” /f:”Feature.xml”

witadmin.exe importwitd /collection:http://MyTFS:8080/tfs/MyCollection /p:”Demo-Agile” /f:”Impediment.xml”

6. Rename Issue and User Story to Impediment and Product Backlog Item

witadmin.exe renamewitd /collection:http://MyTFS:8080/tfs/MyCollection /p:”Demo-Agile” /n:”Issue” /new:”Impediment”

witadmin.exe renamewitd /collection:http://MyTFS:8080/tfs/MyCollection /p:”Demo-Agile” /n:”User Story” /new:”Product Backlog Item”

7. Upload the categories.xml

CD C:\MyDownloadedTemplate\Scrum\WorkItem Tracking

witadmin.exe importcategories /collection:http://MyTFS:8080/tfs/MyCollection /p:”Demo-Agile” /f:”Categories.xml”

8. Upload the ProcessConfiguration.xm

CD C:\MyDownloadedTemplate\Scrum\WorkItem Tracking\Process

witadmin.exe importprocessconfig /collection:http://MyTFS:8080/tfs/MyCollection /p:”Demo-Agile” /f:”ProcessConfiguration.xml”

9. If you want the queries associated with a Scrum project copy them from an existing project.

10. Remove your old reports from your project from the project report page and use tfpt.exe from Team Foundation Power Tools to create new reports.

tfpt addprojectreports /collection:http://MyTFS:8080/tfs/MyCollection /teamproject:”Demo-Agile” /processtemplate:”Scrum” /force

What’s new in TFS 2015

TFS 2015 is now in Release Candidate (RC) and is probably Release to RTM soon. There is a lot of new stuff coming, here are some of my favorites.

The license model

There are a few rather god changes in the license model, the biggest one is that if you are an acceptance tester running test from TFS Web Access you don’t need Visual Studio Test Professional any more, you just need a TFS CAL (client access license).

Team Rooms and Chart Authoring are included in the TFS CAL.

Visual Studio Ultimate and Premium will be merged to Visual Studio Enterprise

Agile planning

There are lots of new things simplifies Agile planning, here are some of them:

Sprint backlog

It’s now possible reorder both PBIs/Stories and Tasks and the sprint backlog, you can also move a Task from one PBI/Story with drag and drop.

Unparented Tasks are shown both in the sprint backlog and in the sprint board.

Customize Cards

Cards can be customized, you can select:

  • To show Work Item id or not
  • To select avatar, avatar and name or just name of the person assigned to the work item
  • Remaining work on a task
  • Tags
  • Up to ten extra fields to be added to the card

Bugs in the backlog or not

You can select if you want bugs to appear on the backlog and boards with requirements (PBIs and Stories) or on the backlogs and boards with tasks or not to appear on backlogs or boards at all.

The Kanban board

In the Kanban board you can now

  • Reorder your PBIs/Stories
  • Add new and edit Work Items
  • Split your columns in Doing/Done
  • Add more swimlanes
  • Add definition of done (DOD)

Other things

  • There is a @CurrentIteration variable in queries so you don’t have to change your sprint queries and charts every new sprint


  • You can share your personal queries with other people for a period of 30 days
  • There are text filtering on backlogs and queries


A wiki is included as part of the Team Project, you use Markdown language to write your content and you can create and edit files directly from TFS Web access. It’s of course possible to edit any file the same way.


There are a lot of nice development features but there are two a really have been waiting for:

  1. You can select if you want “Resolve” or “Associate” as default when you check in code associated with a work item
  2. Intellitest. Intellitest is a way to automatically create unit tests from your code. You need Visual Studio Enterprise for this.

Build and Release Management

The build and release system in TFS 2015 is completely new and is accessible from TFS web access. Apart from being web based it’s also cross platform, you will be able to build Xcode, Android and Java and use things like Ant, CMake, Jake, Maven Puppet and Chef.

First you select what kind of build you want to create.

Then you select your different steps.

And add new ones if you need.


Changes in the builds will be versioned.

The new build system will be ready from TFS 2015 RTM but we will have to wait for the new release system until TFS 2015 Update 1.

Change project name

It’s finally possible to change a projects name.


There is support for REST APIs and Service hooks




Managing security in TFS the easy way

The old way

Before the introduction of Teams in TFS 2012, managing Security was fairly easy, my recommendations to my customers was always the same, use AD-groups and let the TFS Administrator do all the work. Create three AD groups for every TFS project and add them to the TFS project groups.

TFS Group AD-group
Project Administrators TFS-MyProject-Administrators
Project Contributors TFS-MyProject-Contributors
Project Readers TFS-MyProject-Readers


Use the same groups and add them to SharePoint and Reporting Services according to this matrix:

TFS SharePoint Reporting Services
Project Administrators Project site-level Administrator Project site-level Content Manager
Project Contributors Project site-level Contributors Project site-level Browser
Project Readers Project site-level Readers Project site-level Browser


A great tool to help you do this is the Team Foundation Administration Tool in Codeplex

The new way

When Teams were introduced in TFS 2012 things changed, a Team Administrator could add users to a Team and they were automatically added to the project contributors group overriding the project contributor AD groups. I thought a lot about this and spoke to my colleagues at Solidify and my customers and the got the idea to try to skip the project AD groups and let the TFS project completely handle themselves and this way lighten the work load of the TFS Administrator.

Use the build in Security this way:

TFS Comment
Project Administrators The project administrator creates Teams and assigns Team Administrators
Team Administrator The Team administrator assigns members to his/her Teams and they are automatically added to the project contributor groups.
Project Contributors You might consider giving everyone in the Project Contributor group some or all of the following rights to make things easier:

  • Add/Change Areas
  • Add/Change Iterations
  • Create Shared Queries
  • Create builds
  • Create branches
Project Readers


Let the project administrator handle SharePoint and Reporting services the same way if you use them. You might even consider to give everyone read access to all project reporting sites to make thins easier.

Managing Access levels in TFS Web Access

Regardless if you chose the old way or the new way you also have to use the Access Levels in TFS Web Access to Access your users to the right Access Levels.

Acces Level Comment
Stakeholder This level is free and the user can add and change Work Items and se but not change the Agile planning
Basic This is the level for product owners, scrum masters and other people that are not developers but want to do Agile planning. Create the following AD-groups: TFS_CAL_Users and TFS_MSDN_Professional_Users
Advanced This level has access to all parts of TFS web access. Create the following AD-groups: TFS_MSDN_Enterprise_Users (former Ultimate and Premium), and TFS_MSDN_Test_Professional_Users


My recommendations here are that you set the default level to Stakeholder and create AD-Groups for the different MSDN licenses and add them to the Access Level groups. The reason to use AD groups here is that in my opinion that the AD groups are better for audit purposes and if Microsoft decide to change the license levels they are easier to move from one level to another.