Team Alerts as an automated notification tool

Communication among team members is the main pillar for the modern ALM, no excuses.

There are many ways of getting all the team members involved, but sometimes a communication needs to be asynchronous and, more importantly, automated.

Here’s our help: the Team Alerts.

Alerts are customizable on a user basis, but with the new Team concept of Visual Studio ALM, we get Team Alerts. This alerts can be sent when a specific event happen, to a list of users.

In my case, I created a “Test Build Team”, which contains just one user (me J) and it is obviously nested inside the main project team. In a real world scenario, this is supposed to contain all the users whose job is to manage the build.

After that, I can configure a new Team Alert, just for the Test Build Team (when a build fails, it’s triggered)

Then notice some details: thesubscriber is the whole team:

The alert is generated upon a query:

And the alert is sent to the email address of the whole team (so it can be a DL, for instance):

Understanding user loads with the Team Members tab

With the new wave of Visual Studio tooling for Project Management, I’ve been asked for a quick way of understanding commitment of the developers as a high level overview.

There are lots of ways doing so, but IMHO the quickest is the following: the Team Members tab in the Board.

Look at that:

In order to get a full picture I had to zoom it out. It’s pretty messy, and it’s good it is, but it’s not that useful…

So clicking on the team members tab, gives us a pretty comprehensive table:

This is definitely more readable than understanding a full taskboard on the run.

Remote UAC with Standard Environment and Workgroup Machines

As using workgroup machines in Standard Environment is a borderline scenario, there are some issues and stuff to care about, like the careful usage of shadow accounts or the right management of Remote UAC.

In certain scenarios, having Remote UAC enabled may lead to wrong or misleading behaviors, as basically it doesn’t leases a admin token but (correctly, from a security perspective) just a limited one.

For example, the automated installation of the test agent inside a workgroup machine from another workgroup machine running MTM would fail, as this is a scenario where authentication and authorization (two different concept as we know). To workaround this and other cases, the solution is pretty simple. The only need is to set the HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\system\LocalAccountTokenFilterPolicy key to 1.

This procedure is totally supported, as it’s stated inside this MSDN page on Test Controller configuration.