We have to expose our Team Foundation Server to the customers over the internet. One customer is able to log on using the WebAcecss (http://MyDomain:8080/tfs) but when he fires up TeamFoundationServer 2010 to connect to server from there, it simply doesn't work and he got the message: 'The underlying connection was closed: The connection was closed unexpectedly'.
Do you know the answer to this issue?
It seems like an firewall issue. It works when the traffic is routed through Fiddler. (I accidentally discover it when using Fiddler to find out what's going on).
These are 2 interesting articles for troubleshooting this kind of issues that I came across:
https://serverfault.com/questions/397999/team-foundation-server-an-existing-connection-was-forcibly-closed-by-the-remote
http://computech.in/2011/02/the-underlying-connection-was-closed-the-connection-was-closed-unexpectedly-team-foundation-server-does-not-exist-or-is-not-accessible-bypass-proxy-for-team-foundation-server/
Related
since yesterday afternoon at 1.30pm, two separately written applications that access the SagePay payment gateway and the Reporting API Endpoint have both returned the following error:
The server committed a protocol violation. Section=ResponseStatusLine
This occurs in the code at the point of
System.Net.HttpWebRequest.GetResponse()
The payment application hasn't changed since 2009 and was written by an ex-member of staff and is ironically scheduled to be replaced in 3 weeks. The Reporting application was written at the end of last year and has worked since inception until yesterday.
I have spoken to SagePay and they advise that nothing has happened from their perspective and the only thing on my mind was the recent disabling of SSLv3 last month but at the time, the reporting tool was changed to use TLS and I have checked this today and it is indeed using TLS.
Is anyone able to shed any light on what could be causing this please?
Thank you.
OK - I have a fix for this :)
Having spoken to Sagepay, they no longer support Triple DES encryption, only AES. By default Windows 2003 won't use AES - hence the problem.
However, if you install the fix in this article: https://support.microsoft.com/kb/948963 it will enable AES and fix the problem.
BTW, it seems like the link to the hotfix in that article is broken, but this link works: http://hotfixv4.microsoft.com/Windows%20Server%202003/sp3/Fix192447/3790/free/351385_ENU_i386_zip.exe
It does require a reboot, and you will need to disable all protocols apart from TLS1.0 in order for this to work.
We have the same problem. One suggestion is to add the following to the web.config:
<system.net>
<settings>
<httpWebRequest useUnsafeHeaderParsing="true" />
</settings>
</system.net>
This at least avoids the protocol violation, but leads to the following error for me instead:
The underlying connection was closed: The connection was closed unexpectedly.
One other point which I would be interested in your comment on, is that we can only reproduce this error on Windows 2003 servers. On Windows 2008 it works OK. I have also reproduced this on my Windows 7 dev machine by forcing it to connect via SSL3.
I have disabled SSL3 in Schannel for both client and server applications, but I am wondering if it is continuing to connect via SSL3 for some reason, rather than using TLS. Any thoughts?
I have just spoken to someone at SagePay about this who says that this is an issue with the connection using SSLv3. We thought we had disabled this in November last year, but he said that when using Windows Server 2003, he’s heard that sometimes it looks like the SSLv3 is being disabled but that when it gets to the last step it doesn’t do it for some reason.
I'm looking into this now with our server hosts, but this could be something for you to look at too.
I have vs2012 and vs2013 installed on my computer and using tfs 2012. recently when I want to connect to tfs I got this error message:
TF31002: Unable to connect to this Team Foundation Server:
http://MyIpAddress:8080/tfs.
Possible reasons for failure include:
The name, port number, or protocol for the Team Foundation Server is incorrect.
The Team Foundation Server is offline.
The password has expired or is incorrect.
Technical information (for administrator):
The server committed a protocol violation. Section=ResponseStatusLine
I checked all the possible reasons mentioned but there was nothing wrong with them. I tried connecting to tfs using another computer in our network and my own account and it was OK. I can't find what's wrong with my own none of my vs instances can connect to tfs which I was using for months.
I don't know how to fix this, any idea?
try changing your VCS root URL to:
https://abc.visualstudio.com/DefaultCollection
and
with combination of Alternate credential option.(##LIVE##...)
The server committed a protocol violation. Section=ResponseStatusLine
Error went away when I changed the port of TFS server from 80 to 8080. This proved the problem was due to port conflict as mentioned in other online posts e.g. here
I am writing a webdav server for embedded system. Everything goes normal until I tested it with windows client, the miniredir.
It became extremely slow when accessing the data with miniredir. I captured the network traffic and found that everytime I made a move, the miniredir tried to connect to the server via SMB first. (SYN package sent to 137,138,139,445) and the expolrer view would not show until the SMB request failed a few times, which takes more than 20s.
I also tried miniredir with Apache+mod_dav, same delay was observed (make sure the server machine disabled SMB service).
Is there anyone solved this problem? or if there's any work around solution for XP?
BTW: After a few days' debugging, now I believe MS Miniredir is not a qualified WebDAV client. A lot of bugs and shorting comings were reported, but MS didn't do much improvement. http://www.greenbytes.de/tech/webdav/webdav-redirector-list.html
Significant delays can be encountered when accessing WebDAV resources if Internet Explorer is configured to auto-detect proxy servers. Try following these instructions for disabling proxy auto-detection and see if that helps.
After a few days' debugging, now I believe MS Miniredir is not a qualified WebDAV client.
I think this is an overstatement. The only documented issue in XP/SP3 is a by-default lack of support for basic auth, and there is a workaround for this. "When you hear hoofbeats, look for horses, not zebras."
I've been happily using Team Foundation Server with Visual Studio 2010 for the last couple of months at my current place of work when it has suddenly stopped working. I get the following errors:
If I browse to the wiki (Sharepoint) on the TFS server it works fine in Firefox but in Internet Explorer it fails with:
No authority could be contacted for authentication.
I'm not aware of any changes to the server or my machine that would cause the errors and other users of TFS are not affected.
The TFS server is on a different domain to my machine, but usually I get prompted to login and using a domain prefixed username works. At the moment, I don't even get a login prompt anymore.
How do I fix this?
I have recently started to experience a similar issue. We also host TFS on a different domain. Twice in the last week TFS has stopped authenticating users, and I have received messages similar to above. I have no idea what is causing this, but on each occasion SQL Server Agent service was stopped. A reboot of the server and a manual restart of SQL Server agent seems to fix the problem temporarily. I'm not sure if this information is helpful, but I would also really appreciate any help in getting to the bottom of this.
We used a workaround to get past this problem. We configured an entry in the Windows Stored User Names and Passwords tool for the domain of the TFS server. It got around the problem of TFS not prompting for credentials by explicitly supplying them via this tool.
When you change your password for that domain account, you must also change the password here otherwise your account can be locked after failing authentication too many times.
I had the same problem, sorted it by upgrading to tfs2012
In my case, I changed the default port 8080 to port 80 and everything worked fine. but the message could also happen due to wrong saved credentials. you can go to the control panel of the windows and search for credentials manager and then remove your TFS credentials.
I've installed TFS 2008, but I can't seem to access the server. When I try to connect to it in Visual Studio, I can't. If I try by browser on a remote PC, I get a generic page cannot be displayed. On the server, I get a 403. Nothing was touched in IIS and the service is running as a Network Service. Any ideas?
try:
http://localhost:8080/Services/V1.0/ServerStatus.asmx. This will tell you if TFS is up and running. If you are getting anything else you need to look into IIS issues.
I wrote a blog post on diagnosing these types of TFS connections.
http://blogs.msdn.com/granth/archive/2008/06/26/troubleshooting-connections-to-tfs.aspx
The very first thing I do is confirm that it works for a known-good configuration – usually my workstation.
Providing that works and the server appears to be functioning, the next thing I do is ask the user to call the CheckAuthentication web service using Internet Explorer.
The URL for this is: http://TFSSERVER:8080/services/v1.0/ServerStatus.asmx?op=CheckAuthentication
By doing this check, I am doing four things:
Eliminating Team Explorer from the picture
Eliminating the .NET networking stack from the picture
Ensuring that Windows Authentication is working correctly (that’s why I say IE)
Ensuring that proxy settings are set correctly
In most cases I’ve seen, the TFS connection issues are because the proxy settings have changed or are incorrect. Because .NET and Visual Studio use the proxy settings from Internet Explorer, it’s important to have them set correctly.
In rare cases it’s beyond this. That’s when I start looking at things like:
Can you resolve the server name?
Can you connect using the IP address?
Are there HOSTS file entries? (see: c:\windows\system32\drivers\etc\hosts)
Can you ping the server?
Can you telnet to port 8080?
Does the user actually have access? Run TfsSecurity.exe /server:servername /im n:DOMAIN\User to check their group memberships
Have you changed your domain password lately? In some cases they’ll need to logoff the workstation and log back on again to get a new security token.
Is the computer's domain certificate valid? update the certificate: gpupdate /force
Hope this helps.
Turns out the time and date on my computer was not "close enough" to the time and date on the tfs server. Changed my system clock setting and problem went away.
What happens if you send a simple HTTP request to the server directly?
ie:
telnet 8080 [enter]
GET / HTTP/1.1[enter]
[enter]
[enter]
That might give a hint about whether IIS is actually serving anything. If you can do that on the server, what about from a different machine? If the results are different a good guess is there are some security/firewall issues somewhere. HTH a little.
I went through everything on a similar problem.
I logged onto my tfs server and connected directly there.
I also used a TFS admin tool I downloaded some time ago from Microsoft, and made sure I was in all the right groups and projects.
I then went back to the client PC with the problem, tried the services/1.0/serverstatus.asmx?op=CheckAuthentication Url again, and it worked this time.
AFter that full service was restored to my PC.
So I don't have the exact answer, but I would go through the checklists presented by Grant Holliday in his answer.
Add this to the cases for future users, as i had this issue on server 2016...
if your firewall allow only Domain and Private Network, it may not work on client. make sure you give public permission, if server network is set to public...
The error you may face:
ERR_CONNECTION_TIMED_OUT
for
http://fserver:8080/tfs