TFS(On-Prem) Build Agent(On-Prem) Not Finding Visual Studio 2017 Capability While Running As Service

Question

Microsoft Visual Studio Team Foundation Server - Version 16.131.28106.2
Agent.OS Windows_NT
Agent.OSVersion 6.3.9600
Agent.Version 2.136.1

My TFS build agent is not identifying Visual Studio 2017(Enterprise) as a capability while running as a service(under a service account on my primary domain). That same agent does identify Visual Studio 2015 as a capability while running as a service under the same account as above.

I've updated the agent, removed and reconfigured the build agent in question, restarted the agent-service, and restarted the OS. I did notice that when this agent is first configured, the capability is briefly identified while the agent runs under the individual running the configure script, but when the agent switches over to running under the service account, the VS2017 capabilities disappear.

After noticing this, I gave the service account in question read and execute privileges on the root Windows install dir, 'Program Files (x86), and all directories and files associated with the VS2017 install, but this didn't help.

If I run a different build agent interactively(same version as listed above), VS2017 is identified as a capability, so I'm assuming there is something I need to do in regards to the service account I'm attempting to use.

For good measure, within the Visual Studio build task, I tried using the 'latest' option and the 'Visual Studio 2017' options. I also tried adding '/p:VisualStudioVersion=15.0' to the MSBuild args for this task.

Update: I also tried explicitly specifying the capabilities directly in the 'User-Defined' section, and I tried adding the capabilities through the use of environment variables on the agent host.

Answer 1

Have you ensured that the service account user is added as the role service account on the pool the agent is running on? Also ensure that the service account is able to do the following in these Local Security Policies: "logon as a service", "act as part of the operating system", "Manage auditing and security log"

I can't say that this will be able to solve your problem, but I just know that these are necessary in the setups I handle.

You could also for quick and easy test add you service account as an administrator on the machine and test if it finds VS 2017 then. If it does, then you know you need to set some specific groups and permissions.