Wednesday, 19 January 2011

Centralising global TFS alerts/notifications

TFS email alerts are critical to keeping your team informed about changes in the TFS projects they care about. At the very least, most users probably want to know when they've been assigned a work item.

Although Visual Studio 2010 includes the Alerts Explorer (Team –> Alerts Explorer) for signing yourself up for alerts, there's no obvious way to do the same thing for a group of users. Adding custom business logic into the mix really means you'll need to find a better alternative.

Behold! My latest Codeplex project is live, I call it TFS Global Alerts:

When we last faced this problem with Visual Studio Team System 2008, we landed on a solution from'd link to the original blog post but it's been removed from the site. Moving forward a few years, it was recently time to upgrade our TFS 2008 install to TFS 2010 and the question naturally arose about what we do with alerts: continue using the Vertigo web service or not?

The custom logic originally added to the Vertigo solution was flailing a bit due to the kludge of time so we decided to refactor the current solution to better meet our needs and keep everything working with TFS 2010. I've uploaded a generalised version of the end result for your alerting enjoyment as an example of handling TFS events in a web service (you may want to follow the links below for alternatives based on Windows services and event listeners).

The Solution

TFS Global Alerts is, at its core, a web service containing a single public method:

public void Notify (string eventXml)

Notify() accepts a single parameter, a string containing XML detailing the change that occurred and some information about the work item itself. The Notify() method signature changed slightly from TFS 2008: it previously included a second string parameter, tfsIdentityXml. I removed this parameter to get things wired up successfully with TFS 2010.

Most elements in the eventXml look a bit like this—note the OldValue and NewValue child elements:


With the Notify() method called and most of the data you need at hand, sending an email to the relevant parties is then quite simple. TFS Global Alerts does some additional work to exclude the person who made the change from receiving a notification about that change (presumably they know what they've just done!) and avoid sending notifications about code check-ins linked to a work item.

The only real complexity in this code is retrieving an email address for each user from Active Directory. In our production environment I found TFS listed users by display name however in development, with TFS running as a service account in the dev domain, users were returned as domain\username. In production, if a user had multiple accounts (some of our admins), their name was returned as "First Last (domain\username)".

In terms of deployment, I simply deploy the web service to the web server hosting TFS itself and TFS web access.

The notification system hangs off TFS' own event subscription tool, bissubscribe.exe (you'll find it at C:\Program Files\Microsoft Team Foundation Server 2010\Tools\bissubscribe.exe). TFS raises events for all sorts of different happenings and bissubscribe.exe allows you to subscribe an email address or SOAP web service to handle those events.

Since I had some problems creating a server-level subscription, here's the command I use to create a project collection subscription (which captures all events in our case):

bissubscribe /eventType WorkItemChangedEvent /address http://localhost:8080/{vdir_path}/Alerts/WorkItemChanged.asmx /collection http://localhost:8080/tfs/{project_collection_name}


TF50001:  Created or found an existing subscription. The subscription ID is 36


TFS 2010 only sends alerts every two minutes by default and events subscribed to via bissubscribe.exe adhere to the same policy. This can be a bit annoying when you're developing so you may want to dial down the batch wait time. I've included a Powershell script in the solution to configure this but otherwise, check out chrisid's post on the subject.

For additional help debugging bissubscribe, Grant Holliday has some useful tips.

Finally, don't forget to actually configure your TFS server to send email!


If you found this post helpful, please support my advertisers.

Wednesday, 12 January 2011

How to change the service accounts used by TFS 2010

As with many Microsoft products running with specific service accounts, TFS offers an easy way to change the service account it uses or update the account password.

You can do this manually by mucking with application pool identities and database permissions but there's a much easier way using the TFS Administration Console.

Assuming you have the right permissions, fire up the console and click into the Application Tier node; in the Application Tier Summary you'll find two links: Change Account and Reapply Account.


Change Account allows you to change the service account used by the system while Reapply Account allows you to change the password for the currently configured account. You can easily switch from Network Service to a local or domain account (or vice versa) but be sure to grant any local/domain account the Log on as service permission.

If you found this post helpful, please support my advertisers.

Tuesday, 11 January 2011

How to run the Visual Studio Remote Debugger as a Service

I've previously outlined a fairly clunky approach to getting the VS remote debugger installed and configured to start automatically (e.g. in a dev environment); since writing that post, I've since unearthed the remote debugger wizard and the joys (and ease) of running it as a service.

Firstly, the remote debug wizard is not shipped with VS2010 so you'll need to download the rdbgsetup file appropriate for your environment. Run the installer and you'll be prompted to configure the remote debugger once installation completes.

The wizard will present you with the option to Run the "Visual Studio 2010 Remote Debugger" service; check the box and supply an account with Log on as a service rights (the wizard will complain if the account isn't configured correctly).

To grant Log on as a service rights, do this in Windows Server 2008:

  1. Administrative Tools –> Local Security Policy;
  2. Security Settings\Local Policies\User Rights Assignment;
  3. Open Log on a service and add the user you want to configure.

The wizard will also configure the firewall on the machine to be debugged so you'll need to tell it what kind of users you want to allow in.

Once complete, you'll find the Visual Studio 10 Remote Debugger service listed in the Services applet and configured to start automatically. It runs as msvmon100 in the Services tab of Windows Task Manager.

Finally, launch visual studio and connect to the target server (Tools –> Attach to Process or CTRL+ALT+P and enter the name of your server in the Qualifier box.

If you found this post helpful, please support my advertisers.