TFS 2015 – Setting up build agent on separate machineBy Mirek on (tags: build, tfs, categories: tools, infrastructure)
Recently we’ve installed and configured the Team Foundation Server on premise infrastructure. This was described here. In this post I would like to show you how to install and configure the build agent to work on a different machine separately from the TFS server, as it turned out to be quite tricky.
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.
Few other problems are described in this post of Martin Hinshelwood.
7/18/2016 5:43 PMYou made my day!!!!! I had a very similar issue, but creating the user account in the agent machine with the same name and password that I use to access the TFS, it worked!, now the agent appears with the green color and agent pool list, and the builds are working well! Thank you so much!!!!! Sergio.