Using on-prem TFS 2017, I have added an additional agent to an existing pool. The agent is displayed in the pool/queue management pages, is enabled, and is in an idle state. The logs reflect a healthy agent that is listening for work, but the TFS controller won't designate work to it (as far as I can tel). I have tried disabling the other agent as well as stopping the other agent's service. In either situation, the build status states there are no available agents to perform work. I have other agents running in different pools that are all functioning properly, so I am not sure how to determine whats at fault: agent/agent configuration, queue/pool configuration, or the TFS controller it self.
2
votes
Is the error you receive after disabling the other build agent similar to the one specified in this question? stackoverflow.com/questions/31840364/… Then your build may make demands that your newly added agent does not specify as capability? visualstudio.com/en-us/docs/build/define/general#demands.
– Sander Aernouts
Nope. I have all the same capabilities defined for both. It either says no enabled agents are available or that the agent is offline (referring to the original agent, not the one I have added)
– ncarmona
Try to create a empty build definition and queue it with that build agent, then check the result. What's the result if you setup a new build agent?
– starian chen-MSFT
1 Answers
2
votes
I finally found the issue:
While MSBuild and all the relevant Microsoft SDK's required for my builds were installed and properly reflected in the agent's capabilities, Visual Studio was not installed on the new build server.
I was not able to determine why the agent(s) was rejected for insufficient capabilities; we were running TFS 2015 update 2, but after an update to TFS 2017, the agents are no longer dependent on Visual Studio being installed and work just fine running the same build definitions with the MSBuild step.
