4

While configuring a TFS vNext build agent i am getting the error:

ErrorConnectingToTheServer An error occurred while sending the request. the request.

I could not find any other error message in the event log or anywhere else.

Please help.

Update1: The SSL (https///tfs) did not work.but the plain http:// worked.

Update 2: I have removed the old agents and trying to configure new one. While doing that i am getting the below error that is present in the _diag folder:

System.Net.WebException: The underlying connection was closed: An unexpected error occurred on a send. ---> System.IO.IOException: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host. ---> System.Net.Sockets.SocketException: An existing connection was forcibly closed by the remote host .... System.Net.WebException: The underlying connection was closed: An unexpected error occurred on a send. ---> System.IO.IOException: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host. ---> System.Net.Sockets.SocketException: An existing connection was forcibly closed by the remote host .... System.IO.IOException: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host. ---> System.Net.Sockets.SocketException: An existing connection was forcibly closed by the remote host .... System.Net.Sockets.SocketException (0x80004005): An existing connection was forcibly closed by the remote host

Update 3: I have two servers as below: 1 is application server and other is SharePoint and reporting server trying to configure the build in 3rd server. TFS URL is configured with SSL 443.

If I try to configure the agent using http://tfs server/tfs it succeeds, but receives error while building. When i try to configure using https i get the above error. Interestingly I had used this server for two agents, and in that case i had one more server where i am getting the error was working properly.

PatrickLu-MSFT
  • 49,478
  • 5
  • 35
  • 62
Angshuman
  • 697
  • 8
  • 29

2 Answers2

5

I finally found the solution to the issue:

Root cause: TFS vNext agents use .Net framework 4.5... which by default does not support TLS 1.1/ TLS 1.2.

Solution: We need to modify .Net framework registry entry to direct .Net framework to use TLS 1.2. Use the command to update the registry:

reg add HKLM\SOFTWARE\Microsoft\.NETFramework\v4.0.30319 /v SchUseStrongCrypto /t REG_DWORD /d 1 /reg:64 (and/or /reg:32)

Referred here:

https://stackoverflow.com/a/28502562/2939996

Community
  • 1
  • 1
Angshuman
  • 697
  • 8
  • 29
  • I had this issue after upgrading tfs-Server to newer tls Version. Updating the registry made my machine file copy task working again. Thanks a lot! – gReX Feb 11 '19 at 10:19
0

If next time you have encountered some issues during the build agent configuration. For trouble shooting you could check related configuration logs. To see what was going on, you just go to the folder where the agent was installed. In that folder, a _diag folder exists with logging.

The “ServerUrl” setting of agent listed the default URL for TFS. Which default is HTTP on port 8080. According to your update, if you have changed your configuration to run on HTTPS. So, your TFS was not at 8080, but some others such as 443. And you or other co-workers configured the build agent before changed to HTTPS.

If so, you may need to update the “settings.json” file in the build agent folder and replace the old URL with the new one. After changing this file, restart the build agent service, then go back to the Agent Pools, refresh the page.

PatrickLu-MSFT
  • 49,478
  • 5
  • 35
  • 62
  • Are you running on Windows Server 2008 R2? If so , there is a same error info related which maybe helpful https://blogs.msdn.microsoft.com/taylaf/2010/02/10/team-foundation-server-unable-to-read-data-from-the-transport-connection-an-existing-connection-was-forcibly-closed-by-the-remote-host/ & a related hotfix: https://support.microsoft.com/en-us/help/981898/a-file-does-not-download-from-an-iis-7.5-server-that-is-running-windows-7-or-windows-server-2008-r2 – PatrickLu-MSFT Feb 08 '17 at 09:59
  • And what's your tfs server url now `http://tfs-server:8080/tfs` or `https://xxx`? – PatrickLu-MSFT Feb 08 '17 at 10:01
  • Seems you need to Install the Certificate on Build Servers. `If you installed Team Foundation Build Service on one or more servers, you must install the certificate in the Trusted Root Certification Authorities store of each server` To perform builds over SSL, the certificate must be installed in the trusted root store on both the build controller and the build agent. Please take a look at this link: https://www.visualstudio.com/en-us/docs/setup-admin/tfs/admin/setup-secure-sockets-layer#configuring-your-deployment-to-require-https-with-ssl-optional – PatrickLu-MSFT Feb 08 '17 at 10:11
  • i tried that, did not work. I think since my app server is created with CA cert it automatically included in the trusted zone, moreover the same server the agents were working. – Angshuman Feb 08 '17 at 10:31
  • Patrick: do you think TLS 1.2 could cause a issue like this, i am asking because i came to know few days back TLS 1.2 is enabled in the server. If yes how? – Angshuman Feb 09 '17 at 08:31
  • Not sure about this if the issue is related to TLS usually will return an error similar as `could not establish trust relationship for the SSL/TLS secure channel.` For configuring build after switching to SSL usually just need to import that certificate file (.pfx) in the IIS. Have you give a try with restart related service such as build service and agent service? To narrow down the issue, you could also give a try with TLS 1.0 only. – PatrickLu-MSFT Feb 09 '17 at 09:09
  • Another possibility how did you remove the old agents? Did you do it in a clean way? A related question shows [How to delete/unregister build agent on TFS 2015](http://stackoverflow.com/questions/38647095/how-to-delete-unregister-build-agent-on-tfs-2015) – PatrickLu-MSFT Feb 09 '17 at 09:12
  • Yeah i did the same way as the link, btw, i have ran fidller and found that it is trying to use the below: A SSLv3-compatible ClientHello handshake was found. Fiddler extracted the parameters below. Version: 3.0 (SSL/3.0) – Angshuman Feb 09 '17 at 09:41
  • i think i messed up while removing the earlier agents, can you guide me what shall i do to clean up the mess. – Angshuman Feb 10 '17 at 06:52
  • First, try to enter the folders where the old agent is installed/located, check if there is some residual files, if there were, unconfigure the agent again; if there were no. Try to clear TFS cache. Also go through the services check if there are some abandon service with YourAgentName, delete them. Restart related service or TFS server and try to download and reconfigure again. Another option is using a new agent pool to see if it works. – PatrickLu-MSFT Feb 10 '17 at 07:07
  • I had removed all the files already and deleted the services. Also i had tried with a new Pool. Nothing is working. Please help, – Angshuman Feb 15 '17 at 06:46
  • @Angshuman I will configure a test environment with ssl later , any update will let you know. Could you please add a more detail environment of your TFS and build agent server. – PatrickLu-MSFT Feb 15 '17 at 07:28
  • 1
    you know what, i think Fiddler has caused the issue, it has played with the certificates and now it is all messed up. I had to install Fiddler for debugging a different issue, and that has caused this issue. Do you have any idea how to clean the Fiddler mess. – Angshuman Feb 15 '17 at 13:42
  • 1
    To clean the Fiddler mess, seems Fiddler captures traffic by acting as a proxy. Please take a look at this blog [Fiddler conflict with Team Foundation Server](https://devgeeknz.wordpress.com/2007/12/06/fiddler-conflict-with-team-foundation-server/) which may do the trick. I also come up a new idea, have you give a try with directly using IP for server adress in the configuration of the build agent? – PatrickLu-MSFT Feb 15 '17 at 14:58
  • 1
    the above link trick did not work. I think it has more to do with the certificate as you have mentioned earlier, because i could see Fiddler has added a do_not_trust_fiddlerroot cert which by passes the current my or trusted root. – Angshuman Feb 15 '17 at 16:49
  • i have found the issue, i think it has to be taken care by MS. Please see the answer above. – Angshuman Feb 24 '17 at 06:17
  • Confirming - fiddler caused the error in my situation ( same error). – Royi Namir Sep 04 '17 at 09:20