I'm setting up TFS 2015 for my team to try out, and I'm having trouble getting it off the ground. It sounded straightforward, but things don't work and I can't find any diagnostics, and tutorials don't match what I'm seeing. Some highlights:
When I go to download a Build Agent from the server, I don't get a PowerShell file (ConfigureAgent.ps1), I get ConfigureAgent.cmd.
The images and description of setting up the build controller show me a nice picture of the TFS Admin Console with a Build Controller and Build Agent and their statuses underneath 'Build' (see Team Foundation Server 2015 Builds will not start or https://msdn.microsoft.com/en-us/library/ms181712.aspx.) On my system, I see this display under XAML Build Config (the old way,) but the Build item in the console doesn't have anything like that. It has a link to download an agent, but installing an agent doesn't change this.
Installing the agent appears to work. I get a service that's running, and the web portal agrees that I have an agent in the default queue and pool.
But, queuing a build just sits there. I've found the _diag folder for the agent, which has logs with a bunch of "Message received, no message retrieved" lines. I can't find anywhere else to check if the server knows about this build.
The service account is Network Service, and I've tried putting it in every TFS group mentioned online regarding permissions.
My setup is TFS and VS 2015 installed on our build machine, with it also hosting the build agent. I'm on port 8079, because port 8080 is taken. It's got to be something silly I missed, because everything looks like it's working. Has anyone gotten this beast off the ground without coming from a pre-existing install?
The configureagent.cmd is the correct file (it does pretty much what he ps script did)
Make sure the account that the agent is run under is in the "Agent Pool Service Account" role. It is better to use a domain/machine account not a local service account.
Make sure the queue is provisioned in the collection ( https://your-tfs-server:8080/tfs/your-collection/_admin/_AgentQueue ). If not - select "New queue.." and select the existing queue.
Make sure that when setting up the build through web access, the demands (on the general tab) is met by the capabilities of the agent.
If all this is in place, I have found that it facilitates testing by running the agent in interactive mode (not as a service). This gives you a bit better insight into what is happening. When it is working you can configure it as a service again.
Use an actual service account, not NETWORK SERVICE, and make sure that service account is a member of the Build Service Accounts group in your Team Project.
For me the issue was that the IIS's Team Foundation Server site setting's Authentication, "Windows Authentication" had to be enabled.
I was using a windows user as the log in credentials for the Build Agent running as a service.
Remember this new build system uses all http now.
It does not talk to any tfs build controller.
Related
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.
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.
I recently installed TFS 2015 on a new machine. I want to configure the same machine as our build server but i have massive trouble doing this. I neither can configure the new vNext-system nor can i configure an "old-style" xaml build server. As the build account i want to use the NT AUTHORITY\Network Service. For the xaml configuration i set "Execute service as" to NT AUTHORITY\Network Service and use the same account for the connection to the team foundation server.
But when i add a new controller and want to browse to custom assemblies, i get a "service unavailable" error. So i decided to test without the custom assemblies, added an build agent and created a new build-definition for a simple test project. I added a build to the queue and wait. Nothing happenend (in the build window) until after about 50 seconds an error was shown in the build window: Service Unavailable (Typ VssServiceResponseException).
Same for the new vNext builds. I downloaded the agent.zip from the web-frontend, opened the powershell and started configuring the build-agent. After waiting some minutes, the configuration aborted with.... service unavailable.
So i decided to test something different : instead of using the FQHN, i used localhost and - tataaa - it starts the agent, which is also shown green in the web-frontends agent-tab. So i created a new vNext-Build-Definition and added it to the queue, but it does not start, but shows the message : "waiting for console output from an agent".
So i decided to test it on a different pc : i downloaded the agent to my laptop and installed it, configuring the agent with it's FQHN. Without any problems the agent was started and i was able to start and run a build.
So the question is : Why am i'm not able to configure the build service on the tfs. I guess it has something to do with permissions, but i don't now, what permissions the network service account should have. I also tried it with a local account, but with the same result.
Any hints are very appreciated. Thanks in advance.
BTW: I can ping the FQHN from the command-line.
This is the output, after trying to add a vNext-agent via the powershell.
UPDATE:
I used the the servers IP-address instead of its name and it suddenly worked.
Take XAML build for example, to configure a Team Foundation Build Service, you must be a member of both the Windows Administrators security group on the server on which you are configuring Team Foundation Build Service and the Project Collection Administrators group on TFS.
According to the second paragraph, you can configure build controller and add build agent. Before queuing a build, you need to make sure the build controller and agent are in Ready status, sometimes relevant services are not yet fully available when you newly configure them or restart them.
Also, you may try to remove build service feature, and reconfigure it, to see whether you can solve the issue.
I'm looking at migrating our builds from the old XAML to the new build system, but I have a problem with configuring the build agent to run as a service.
Configuring the agent to run interactively (in my session on the build server) works. The builds are OK but this is not useable as I have to open a session and start the agent.
Configuring the agent to run as a service with the default NT AUTHORITY\NETWORK SERVICE works. The builds are broken. WiX doesn't like this account and fails during the ICE validation. The drop also fails because this account doesn't have access to the drop folder.
Configuring the agent to run as a service with a domain account fails. The service is not created and I get the following error:
Installing service vsoagent.tfs-server.tfs-build-server-agent1...
Creating EventLog source vsoagent.tfs-server.tfs-build-server-agent1 in log Application...
An exception occurred in the OnAfterInstall event handler of System.ServiceProcess.ServiceInstaller.
System.NullReferenceException: Object reference not set to an instance of an object.
The username and passwords are OK, I get a different "bad username or password" error when typing a bad password. The user was used for the old XAML build system on the same build server and is in the local admin group, so it has authorisations AFAIK.
I was running TFS 2015, I upgraded to 2015 update 1 then forced an agent update in the web interface. After that it works, I can configure the agent to run as a service using a domain account.
Agent.Version is still saying 1.83.2 in the web interface, but the files are actually different in the agent folder. An agent.old folder is left after the upgrade and you can see that VsoAgent.exe and VsoAgentService.exe have a different size and version. Also the agent.old folder has 138 files in 46 folders, but the agent folder has 157 files in 53 folders.
I Had the same issue with the WIX validation. But i did not try to reconfigure the agent (not due to problems,just due to pure laziness), instead i did just change the account to a domain account using the services overview. restarted the machine and everything did work fine.
To narrow down your issue:
1.Try to Configure the agent to run as a service with another domain account on another computer
2.If you need to change the logon account, don't do it from the services snap-in. Instead, From an elevated Command Prompt, run: C:\Agent\Agent\VsoAgent.exe /ChangeWindowsServiceAccount
update
If you upgrade your TFS2015 to TFS2015update1. Do not just use the simple update agent in the web interface. You need download the agent from web and reconfigure it in the cmd.
I need to create an on-prem build agent that pulls its source code from Visual Studio Online. I found a great blog post that describes how to do this here: blog post
My problem is, after following the steps my build service shows it's at a state of "Pending" rather than "Started" and I don't get to see the controller or agents in the TFS admin console as shown below:
I don't have a full on-prem TFS installation - I just have the newly installed build components.
I see the following error in the event log after 15 minutes:
Exception Message: The http request operation timed out after 00:15:00. (type TimeoutException)
Exception Stack Trace: at Microsoft.TeamFoundation.Build.Hosting.BuildMachine.StartOperation.End(IAsyncResult result, HttpRouter& router, TfsMessageQueue& messageQueue, List`1& processHosts, MachineLifecycleActivity& traceActivity)
at Microsoft.TeamFoundation.Build.Hosting.BuildMachine.EndStart(IAsyncResult result)
at Microsoft.TeamFoundation.Build.Machine.WindowsService.EndStartMachine(IAsyncResult result)
It turned out this problem was firewall related but nothing to do with port 9191. I think only port 443 is used. The problem seemed to relate to the fact that I had a domain account for the build service but need to use my hotmail account for the service to authenticate with visual studio online to pull down the source code. The build service was able to cope with this ok but the internet proxy service that "protected" the client's network needed additional configuration
Although that was the cause of the problem, whilst attempting a fix, I moved to using a TFS2015 build agent as Buck suggested. I downloaded the agent from the visual studio online site. I am now using the new web based build designer rather than xaml and I have found it to be excellent and it builds BizTalk solutions just fine - thanks for the advice Buck :)
I'm working on automating our build process using Team Foundation Build 2010. When our TFS Server was installed, whomever installed it didn't install the Build Configuration Services so this node is missing from the TFS Admin Console. I'm pretty sure I know the answer to this but I wanted to check in case I'm missing something. I'm also asking because the TFS Server is a production server and my supervisors do not want to install anything on this server. Can the Build Services be installed on another machine or VM and still have the Build Configuration Node appear in the TFS Admin Console? I know the Build Controller as well as the Build Agent can be installed on another machine or VM. I just wanted to get clarification on the "Build Configuration Services" piece. Thank you
Absolutely! This is actually a very typical scenario. I don't normally recommend for people to install the build services on any of the application tier servers. When you install only the build features, the TFS Administration Console will show only the build features.
By installing it on separate machines, you can create a build farm of a build controller with multiple build agents. It scales very well.
Build servers would be considered "production" servers in my opinion as well. They don't have the same disaster recovery or monitoring requirements though. If a build machine dies, just image another one and add it to the pool. This is essentially how the elastic build service for the Team Foundation Service (aka TFS Preview) currently works. They get destroyed after each use.