TFS 2015 – Setting up build agent on separate machine

My way to successfully set up the build agent for TFS 2015 was basically a try and fail process. I get an error, I found a solution I run the build again, then I get another error and so on. That’s why I will present you the result same way with a fail and success steps.
The machine where the build agent is going to be installed runs on a different domain than the TFS Server. So first we go to the TFS web portal and download the build agent, unzip it and run the ConfigureAgent script to install it on the build machine

This process is similar to what I have already described in aforementioned post. Set it to run as a windows service leaving defaults for other parameters. That was easy and you should see your agent running as the windows service. Unfortunately when you go to the TFS portal and check if the agent is online you will see this

Build agent is registered but not available.  Let’s see what we can find in the agent’s log file. It can be found under [AgentFolder]\_diag\ directory. Among many other messages we find this

Microsoft.VisualStudio.Services.Common.VssUnauthorizedException: VS30063: You are not authorized to access http://server2012.northeurope.cloudapp.azure.com:8080.

After quite deep googling it turned out that the only workaround for this is a sort of hack. You have to create a shadow account on the agent machine with the user name and password exactly matchin the account which is used to access your TFS server! Then the build agent service must by running under this account. To achieve it create such local user on the build agent machine then go to properties dialog of the build agent service and set new user name and password in Log on tab. After restarting the service you should finally see it running green on the TFS web portal.
Next you try to run a build, but after a while it fails with no message on the console. Strange! Go to build agent logs again and you find this

AccessDeniedException: Access denied. serveruser needs Listen permissions for pool Default to perform the action.

As described here we need to add our user account to the Agent Pool Service Accounts like this

Next try… and again no log in the build console and the agent log file says

System.Net.WebException: The remote name could not be resolved: 'server2012'

That was easy and turned out to be an incorrect notification url. Just need to go to the TFS administration console (on the TFS machine this time) and under the Application Tier update the Notification URL to be the one available for public.

However another try showed yet another denied access

Access denied: serveruser does not have write permissions for orchestration plan 24b0d805-3e8b-41e5-8eb4-4f6cd66bf8fc

This time another place where we have to add our build account. This is a Project Collection Build Service Accounts

And finally, it worked and the build passed through. As you can see this is quite overkill if we want to have a build agent on a separate machine. Either I totally missed something and did it wrong or there is a huge need for user friendly improvements in this process.

Cheers

Few other problems are described in this post of Martin Hinshelwood.