tirsdag 17. juli 2012

How to setup a dns friendly Team Foundation build service environment in TFS 2012

When we setup a Team Foundation build environments, we focus on getting the environment as dns friendly as posible. We don’t want the build masters to spend time resolving obscure machine names, and certainly not rembemer them! When the build master get notified on build service issues, he should be eable to directly RDP to the correct machine based on the logical domain and not the physical (i.e. machine names). So i figured i just share our 5 cent’s on how we setup an dns friendly TFS build environments. You can see this as an extension of Ed Blankeships blog on setting up dns friendly TFS environments.
The convention is quite simple and it makes it’s very easy to RDP to the correct build server when issues are reported by the development teams.
Naming convention for build controllers:
i.e. buildcontroller.defaultcollection.contoso.local
Naming convention for build agents:
build<number>.<collectionname>.contoso.local – Agent <number>
build1.defaultcollection.contoso.local – Agent 1
build1.defaultcollection.contoso.local – Agent 2
build1.defaultcollection.contoso.local – Agent 3

build2.defaultcollection.contoso.local – Agent 1
build2.defaultcollection.contoso.local – Agent 2
We recycle the agent number on each build server since it is a local resource.
In some scenarios build agents and buildcontroller are on the same machine, if so we don’t skip one of the dns aliases; we don’t want to break the convention. i.e. the machine QOPRSA12312.contoso.local has both buildcontroller and build agents installed, so we make two dns aliases:

buildcontroller.defaultcollection.contoso.local  –> QOPRSA12312.contoso.local
build1.defaultcollection.contoso.local             –> QOPRSA12312.contoso.local
The reason for having build service name first and not collection name, is that this corresponds to the logical grouping in the organization; Teams work on work on Team Project collections, not on build services, so the ALM view should reflect this. i.e on the domain controller resources are grouped by collection names not buildcontroller og build machines (see image below).
On the domain controller:
This how it looks visual studio:image
The build log:
So if there is a problem the build master can now just RDP directly to build1.defaultcollection.contoso.local:
We are open to opinions on how this is setup, but in our environment and for our customers this works very well Smilefjes.
Happy ALM’ing

onsdag 13. juni 2012

Using PUT action with APIController in asp.net mvc 4

I have this very simple PUT Action Method

  1.     public class FeedItemController : ApiController
  2.     {
  3.         [HttpPut()]
  4.         public void Put(int id, string status)
  5.         {
  6.         }
  7.     }

And the corresponding jQuery script:

  1. var url = '@Url.RouteUrl("DefaultApi",new { httproute="", controller="FeedItem", id=2,status="done"})';
  2.    $.ajax({
  3.        url: url,
  4.        type: 'PUT',
  5.        success: function (result) {
  6.            // ...
  7.        }
  8.    });

No matter what I tried I always got a 404 error…
Finally, I gave up changing code and looked at the debugging environment and I found that I was using IIS Express for debugging.


I changed it to “Use Visual Studio Development Server” and voila it worked!

Apparently IIS Express is not configured by default to support the PUT word. To change this open up C:\Users\<YourUserName>\Documents\IISExpress\config\applicationhost.config” and change the line for the ExtensionlessUrl-Integrated-4.0” handler to


  1. <add name="ExtensionlessUrl-Integrated-4.0" path="*." verb="GET,HEAD,POST,PUT,DELETE,DEBUG" type="System.Web.Handlers.TransferRequestHandler" preCondition="integratedMode,runtimeVersionv4.0" />

And don’t forget to add the PUT word to your production IIS server ;)

onsdag 9. mai 2012

Localization issue in TFS 11 Team Web Access: “object doesn’t support this action”


A customer of us had an issue with the new Team Web Accessen in TFS 11. The error she got was the client jscript error: “Object doesn’t support this action”


If the user opened up a work item, the fields where empty and UI elements where distorted.


In the script debugger we found the following error:

UserAgent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; GTB6.6; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; InfoPath.3; .NET4.0C; .NET4.0E)

Timestamp: Wed, 9 May 2012 10:42:23 UTC
Message: Objektet støtter ikke angitt egenskap eller metode
Line: 4
Tegn: 1617
Code: 0

The problem was the localization on the local computer (no-NO), while the query was using loc=en-US. The solution was to change the localization to “en-US”. After we changed the localization everything worked as normal.

fredag 4. mai 2012

.Net 4.5 disables connection to remote database


After I installed .net v4.5 i ran into the following problem:

A connection was successfully established with the server, but then an error occurred during the pre-login handshake. (provider: SSL Provider, error: 0 - The wait operation timed out.)

The funny thing was that the error only occured when connecting to a remote SQL server. The bug is reported on  Microsoft Connect.

The work around for me was to remove non-IFS LSP installed Winsock Catalog Provider as described in the KB 2568167.

tirsdag 17. april 2012

Trace/logging configuration in Team Foundation Server 11

Here is list of the different trace configurations I use when trying to track down an exception in the TFS.

1. TFS Configuration logs:
Tracing configuration changes
2. TFS Application Tier Trace:
Tracing spesific component in the TFS server. API, Security etc
3. TFS Application Tier Request trace
Trace URL requests to the application tier.
4. TFS Client side trace logging
Traceg TFS traffic from the client side i.e. Visual Studio, office or custom application.
5. TFS 11 Team Web Access trace
Trace for Team Web Access.
TFS Configuration logs

The Configuration logs are used when tracking issues during TFS configuration, such as migration/upgrading/backup/attach/detach etc etc.

The logs are available from the TFS Admin console and/or directly from

C:\ProgramData\Microsoft\Team Foundation\Server Configuration\Logs

TFS Application Tier Trace Logging
The TFS application Tier Trace logging enables component level trace logging on the App tier. These logs track all usage of the app tier. To configure the App Tier logging do the follwing: 

1) Open the web.config at C:\Program Files\Microsoft Team Foundation Server Dev11\Application Tier\Web Services\

2) Locate the appSettings block and append the following keys:

<add key="traceWriter" value="true" />
<add key="traceDirectoryName" value="%TEMP%\\TFLogFiles" />
Remember that the %TEMP% folder is the folder for the identity of the application pool for the TFS web application. The App pool identity can be found at
IIS Manager-> Application pools ->Microsoft Team Foundation Server Application Pool -> Advanced Settings:


The folder will be: C:\users\[TFS APP POOL IDENTITY]\AppData\Local\Temp\TFLogFiles

3) To control the diagnostic level go to the system.diagnotics section and change the different trace level for the switches:

<assert assertuienabled="true" />
<trace autoflush="false" indentsize="4" />
<!-- Trace Switches
Each of the trace switches should be set to a value between 0 and 4, inclusive.
0: No trace output
1-4: Increasing levels of trace output; see Systems.Diagnostics.TraceLevel
<add name="API" value="4" />
<add name="Authentication" value="0" />
<add name="Authorization" value="0" />
<add name="Database" value="0" />
<add name="General" value="0" />
<!-- WorkItem trace switches -->
<add name="traceLevel" value="4" />

To enable these settings for a certain service go to

Valid web services are: Build, services, VersionControl, Warehouse, and WorkItemTracking

i.e. setting up trace for the VersionControl service

It is not possible to have a trace filter on both service type and component i.e. serivce = Build and component = API.

Remark: when using the web service for setting the trace level, it is not persisted. Thus when the app pool is recycled these settings will be lost. To persist the settings you must use the web.config, but then again you are only able to enable/disable on component not on service level.

TFS Application Tier Request trace
If you want to trace the web request to the application tier you can change the ASP.NET trace. This configuration is also located in the app tier web.config (C:\Program Files\Microsoft Team Foundation Server Dev11\Application Tier\Web Services\)

<trace enabled="true" requestLimit="10" pageOutput="false" traceMode="SortByTime" localOnly="true" />

The trace parameters are described at

To view the trace go to:

TFS Client side trace logging
If you are doing customization to the TFS you might want to enable client side logging. This is done by adding a diagnostic block to the app.config. i.e. Visual Studio trace: devenv.exe.config or word word.exe.config. If the file doesn’t exists just create it and add the following configuration block

<?xml version ="1.0"?>
    <add key="VersionControl.EnableSoapTracing" value="true" />
    <add key="VersionControl.TraceDownloadContent" value="false" />
    <add key="VersionControl.EnableCompression" value="true" />
    <trace autoflush="false" indentsize="4">
        <add name="traceList" type="System.Diagnostics.TextWriterTraceListener"
         initializeData="C:\Temp\TFS.log" />
  <add name="TeamFoundationSoapProxy" value="4" />
        <add name="VersionControl" value="4" />
        <add name="API" value="4" />
        <add name="General" value="4" />
        <add name="Database" value="4" />
        <add name="Authorization" value="4" />
        <add name="Authentication" value="4" />

Team Web Access trace
Tracing the TFS 2010  was possible by enabing the TWA switches (TSWA.General, TSWA.UserControl +++ ) in the diagnostics block, but since the TWA has been completely rewritten it does not seems to work any more.

But don’t despair, using reflector i found a way of enabling trace for the Team Web Access. Trace filters can be enabled by using the registry string “TFS_RAW_TRACING_ENABLED”. 

The trace filter contains the filter settings using the form KEY=VALUE. Each key/value pair pair is separated by a ‘;’. 
They must contain values for the following filter keys: 
Tracepoint, Area, Level and Layer.
By using reflector on the assemblies in the TWA bin folder you can search for any of the Trace* methods in the class TeamFoundationRequestContext or the static TeamFoundationTracingService.TraceExceptionRaw
Here is an sample from the SaveWorkItems method in the TeamFoundationWorkItemService class:

TeamFoundationTracingService.TraceExceptionRaw(0x927bf, TraceLevel.Error, "WebAccess", TfsTraceLayers.Controller, exception2);
This translates to the follwing trace filter:
               Tracepoint= 599999;
               Area = WebAccess;
               Layer = Controller;
               Level = Error;

Here are som other trace filters:

WebAccess exception logging: 
    Tracepoint = 520010 
    Area = WebAccess 
    Layer = Controller
    Level = Error

Exception in the web service handler:
Area = TeamFoundationWebService
Layer= WebSevice
Tracepoint = 0 
Level = Warning

DataLayerAccess Update WIT xml:
     Tracepoint = 900116/900115
     Area: DataAccessLayer
     Layer: DataAccessLayerImpl
     Level: Verbose
To enable the trace filter just add the string value 


to the 

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment\

and enter the trace filter i.e. Level=Verbose;Area=WebAccess;Tracepoint=0;Layer=Controller

In addition to the base trace definition, it is possible to have up to 10 additional tracing parameters defined by the registry values ‘TFS_RAW_TRACING_ENABLED_[1-9]’

The logs are available in the EventViewer under 
“Application and Service Logs” -> Microsoft-Team Foundation Server –> Debug
Here is the Exception trace during a work item save

lørdag 24. mars 2012

Collation conflicts in TFS 11 beta.

Over the years we have consolidated several Team Project Collections into one database instance. The collation on the collection databases varies, which was not a problem in TFS 2010. When we migrated to TFS 11 Beta, we ran into problems when we tried to associate artifacts to work items.
In Microsoft Test Manager we got “The Bug could not be saved, cannot resolve the collation conflict between….”

and this descriptive message box (“There is a problem on the server”) when we tried to link attachment to work items.
and the associate work item to changeset Checkin’ policy started to give us messages such as

“Changeset NN successfully checked in.
Failed to update the following work item:
ID XX. Reason: There is a problem on the server.
Contact your Team Foundation Server administrator.”
If you tried to manually associate changset to work items  we got:

The MTM error is obviously related to collation issues, but to pinpoint the cause for the other two, we ran a SQL trace and we got loads of MS SQL Error 468, wich are collation erors.
We saw that the team project collection databases had a different collation than the database instance.  There are several ways of resolving collation issues, but the recommendation I got from an SQL expert is not to try to change the collation directly, but to reinstall the database instances with the correct collation.
This is how we did it:
1.       Stop/Detach the team project collection databases
2.       Take backup of TP collection databasess
3.       Reinstall database instance(s) with the correct collation.
4.       Restore each TP collection into a database with a matching collation
5.       Attach the team project collection databases.
and that fixed the problem.

Since we hade 4 different collation types we had to install one database instance for each collation!!! Now we are running 4 database instances...