I have a remote developer connected to my TFS via the internet. When he attempts to do a GET from source control, he fails to get a number of files with error messages as this:
D:\CaseTrakker\CaseTrakker_v6_0\CaseTrakker\CaseTrakker.ObjectModel\Framework\Factories\Value\LookupValueViewModelFactory.cs: Please contact your administrator. There was an error contacting the server.
Technical information (for administrator):
HTTP code 302: Moved Temporarily
This does not happen for all files, but for many, and repeated retries does not resolve it. I am at a complete loss.
Possibly germane, the way that I have published my TFS is to set up a rule in my firewall to route requests targetting http://publicserver:8080/tfs to http://internalserver:8080/tfs. Since this error seems to have to do with redirection, that might be some or all of the issue.
Thanks in advance for any assistance.
David Mullin
IMA Technologies
Might be worth getting the external developer to upgrade to the latest Update 3 CTP of VS 2012 as there was a fix in it to handle retries better on downloads.
However, you'll probably have more luck if you configure it so that your TFS server is accessible over the same fully qualified domain name both internally and externally (internally resolving to the internal IP - externally resolving to your external IP). Check out this word document for more information (http://www.christiano.ch/common/documents/Exposing_Team_Foundation_Server_to_the_Internet.docx) or take a look at the Pro TFS 2012 book.
Related
This question is purposefully general because I'm trying to understand things more from an architectural perspective, because that will impact which group I need to contact. My team is using Azure DevOps (cloud) with on-prem build agents. The agents connect to ADO via a proxy.
We use several tools in-house provided by vendors with ADO plugins in the Marketplace that require us to set up service connections. Because the services are installed on-prem, the endpoints we enter are not available via the Web (e.g. https://vendor-product.my-company.com).
If I log into the build machine and open up IE, I am able to connect to the service endpoint URL. However, whenever I try to run a task from ADO, it fails with some kind of connection-related issue ("The underlying connection was closed: An unexpected error occurred on a send", "Task ended with an exception: Error: read ECONNRESET", etc.).
The way I thought it worked, all the work takes place on the build machine itself, so the calls would be going from my-build-server.my-company.com to https://vendor-product.my-company.com. Those error messages though make me wonder if the connection is actually coming from https://dev.azure.com.
So the questions I have are:
For situations like this, is the connection to a service endpoint going to be seen as coming from my on-prem build agent, or from ADO (or does it vary based on how the vendor writes their plugin)?
If the answer to #1 is "it varies", is there any way for me to tell just from the plugin itself without having to contact the vendor? (In my experience some of the vendor reps don't understand how the cloud works.)
and/or
Because my build agent was configured to use a proxy when I set it up, is it going to use that proxy for all connections, even internal ones? I think I can set up a proxy bypass list for the agents but I presently only have read access to the build box. I can request temporary elevated access but I'd need some level of confidence that's what the issue is.
Hope I explained the situation clearly, thanks in advance for any insight.
I am using Web IDE and want to see the log by clicking on the arrow.I can only see an empty "Untitled" page. The Node.js app is running normally. Live edit is switch off.
After some minutes:
Gateway Timeout
The proxy server did not receive a timely response from the upstream server.
Reference #1.45bf1402.1511018717.3dddb8b
I'm not for sure what Web IDE you are referring to. The only one I'm aware of is the DevOps (which works for me below):
It seems to me like this error that you posted would indicate a temporary outage. Is it still an issue?
In any case, I would advise opening a support ticket if you encounter this issue again (more details about your account would help). I think the Bluemix proxy will time out requests if they take too long.
We are trialing a test migration of a project on TFS 2010 (on prem) to #visual-studio-online using #OpsHub . During the migration phase at the user mapping window we are getting the below error message.
2015-07-08 15:10:49,916 [4] ERROR Error : The operation has timed out
at System.Net.HttpWebRequest.GetResponse() at
Microsoft.TeamFoundation.Client.Channels.TfsHttpWebRequest.SendRequestAndGetResponse(HttpWebRequest
webRequest, WebException& webException)
I am not able to find much information on-line about this error. I tried doing the migration as a TFS administrator and as a domain user who has project admin access to the project but still get these time out errors.
I saw online a user upgraded to #OpsHub 1.3 from 1.2 to overcome this issue which I tried but still doesn't help. Do we need to open any other ports for this to work apart from 80 and 443? Any suggestion as to how to over come this issue?
From the logs we find out that error is about time out from your local tfs server.
Server Error : TF400324: Team Foundation services are not available from server tfs.nextdigital.com\Next Digital.
Technical information (for administrator):
The operation has timed out
Here you need to work with your tfs admin to increase timeout parameter of your tfs.
Following thread might help you in this.
http://blogs.msdn.com/b/ablock/archive/2008/09/16/increasing-the-time-out-time.aspx
Thanks & Regards,OpsHub Support
I posted on friday regarding this issue and received no response, however since then some updates have occurred which might affect whether people have an answer to my question or not.
I'm trying to deploy an MVC website to Azure, and in this particular project the web deploy receives a Socket Error 10054 and gives up after 10 attempts saying it was Unable to write data to the transport connection. It makes varying progress in between the socket failures but never completes within the 10 attempts.
I have since had a play around with other projects which are deployed to different url locations within this same Azure Account and they deploy fine! I think this means the problem is not on my end, i.e. port 8172 is open and deployment can be achieved with my current local settings.
What are the problems that can cause this socket error 10054? I saw somewhere that I should enable the "Allow untrusted certificate" option when deploying but I can't find that option within VS 2013.
Any ideas are welcome please,
This issue is driving me mad, it seems there's a real mixed bag of solution ideas which have worked for others but not me.
JK
I have an agent and a server in different domains. The server acts as an MSMQ server and the agent acts as an MSMQ client. I am using the mqsender utility, which is part of the MSMQ tools.
My problem is that a message is not delivered when using the HTTP:// format string (the MSMQ is installed with HTTP support). Using the OS: format string works fine.
When using HTTP the messages are immediately moved to the Dead Letter queue and the Class is set to Unknown, so I do not know the reasons for this behaviour.
So, this works:
mqsender.exe /c:10 /j:dead /f:Direct=OS:il-mark-w2k3\private$\test
And this does not:
mqsender.exe /c:10 /j:dead /f:Direct=http://il-mark-w2k3/msmq/private$/test
I checked that MSMQ virtual directory exists. How can I trace the MSMQ operation to try and understand what is going on?
Thanks.
EDIT
All the commands work as expected when ran locally on the server.
Navigating to http://il-mark-w2k3/msmq/private$/test in the browser on the agent (and the server) results in 501 - Header values specify a method that is not implemented. The same error is received when navigating to http://il-mark-w2k3/msmq. I suppose that is OK, after all it is not 404 - Not Found, right?
EDIT2
I have succeeded to resolve the issue. IIS lacked Anonymous Authentication, it became obvious from observing its log - 401.2 HTTP error was there. All worked well after it was enabled. The mistery remains why did MSMQ display Class Unknown on the dead messages? On other machine the same setup produces Error : 401, which makes much more sense.
The logging for MSMQ is internal so you won't easily be able to see exactly why the message didn't get delivered without raising a support case with Microsoft.
I have a few blog posts on solving various MSMQ/HTTP issues.
The 17 entitled "MSMQ messages using HTTP just won't get delivered" may help.
Also make sure you check the IIS logs for information.
Cheers
John Breakwell