Welcome to EMC Consulting Blogs

With the above configuration there are basically two problems we need to overcome:

• The Build Agent that runs as a Windows service called ‘Visual Studio Team Foundation Build’, will need to authenticate with the TFS AT in order to consume the various web services (e.g. source control, work item tracking, publishing build results etc.)
• The TFS AT will need to authenticate with the Build Agent service in order to be allowed to start a build

Build Agent to TFS Authentication

Solving the first problem involves storing a saved password in the profile of the Build Agent’s service account, in this scenario ‘DOMAINB\TFSBuild’, and ensuring that the server will use that credential automatically.

1)	Log onto the Build Agent server as the ‘DOMAINB\TFSBuild’ user (or equivalent)
2)	Open the ‘User Accounts’ Control Panel applet (also called ‘Stored User Names and Passwords’ on Windows Server 2003)
3)	Select ‘Manage your network passwords’
4)	Add an entry for the server running the TFS Application Tier (you may want to add two, one for the server’s NetBIOS name and another for the server’s FQDN). The username you enter here needs to be an account in the ‘DOMAINA’ domain that is a member of the ‘Build Services’ application group in the Team Project(s) the Build Agent will be servicing.   Here you can see both the NetBIOS and FQDN entries for the TFS server have been added.
5)	Review the Internet Explorer security settings of the ‘Local Intranet Zone’ and ensure that the ‘Automatic logon only in Intranet zone’ is selected.
6)	By default the FQDN of the TFS Application Tier is unlikely to be treated as being in the Intranet Zone, so we need to add it explicitly.
7)	You should now be able to test these changes by opening Team Explorer and verifying that you are able to transparently connect to the TFS server (i.e. you aren’t prompted to enter credentials).

TFS-to-Build Agent Authentication

Having completed the above, we now just need to solve the second problem.  My approach was to create a local account on the Build Agent with the same username and password as the account used as the identity of the ‘Microsoft Team Foundation Server Application Pool’ on the TFS Application Tier.  This has the effect of allowing the TFS Application Tier to authenticate to the build server using it credentials.

As an alternative to this, you could setup a saved password, this time on the TFS server, in the profile of the ‘DOMAINA\TFSService’ account for the build agent server that use a domain account in ‘DOMAINB’ or local account on the build server.

At this point you should be able to register the new build agent in your Team Project and queue a build to it.

Troubleshooting

If you have hit problems whilst trying the queue the build, then this indicates that the TFS Application Tier had a problem connecting to the build agent.  This is typically caused by TFS not being able to authenticate to the build agent or some kind of firewalling preventing the network connection, usually via TCP port 9191.

If the build starts but quickly fails, then this generally points to either or both of the following:

1. The Build Agent service account cannot authenticate to the TFS Application Tier (i.e. a problem with its saved username/password).
2. The saved username/password has not been added to the ‘Build Services’ application group in the relevant Team Project.

Anyway, if you find yourself in this sort of edge case scenario then hopefully the steps detailed here will be helpful.  I'm now wondering whether a similar approach could be used to workaround the issue of not being able to add users, from a Trusting domain, to TFS application groups when there isn't a 2-way trust in place...?