locked
User not in the Admin group + An existing connection was forcibly closed by the remote host RRS feed

  • Question

  • I cannot connect to my Controller. If i go to the Test Controller Manager in the lab center my controller is listet as offline. If i press F5 in order to try to reconnect the following exception is logged in the application event log:

    (QTController.exe, PID 2292, Thread 7) User not in the Admin group.

    I have checked that admin group and that looks ok. I have tried using network service or and domain account. No difference.

    In the TestControllerConfigUI.log i have the following:

    I, 2010/09/12, 18:47:57.541, The test controller service account already has the required permission on Team Foundation Server.
    I, 2010/09/12, 18:47:57.541, Registering controller: TFSTESTCONTROL:6901 with TFS server: http://tfs.tfs2010.test.proactive.dev:8080/tfs/defaultcollection
    I, 2010/09/12, 18:47:57.541, Creating Channel
    I, 2010/09/12, 18:47:57.541, CreateControllerObject: attempt 0, System.IO.IOException: The write operation failed, see inner exception. ---> System.Net.Sockets.SocketException: An existing connection was forcibly closed by the remote host
       at System.Net.Sockets.Socket.Send(Byte[] buffer, Int32 offset, Int32 size, SocketFlags socketFlags)
       at System.Runtime.Remoting.Channels.SocketStream.Write(Byte[] buffer, Int32 offset, Int32 count)
       at System.Net.Security.NegotiateStream.StartWriting(Byte[] buffer, Int32 offset, Int32 count, AsyncProtocolRequest asyncRequest)
       at System.Net.Security.NegotiateStream.ProcessWrite(Byte[] buffer, Int32 offset, Int32 count, AsyncProtocolRequest asyncRequest)
       --- End of inner exception stack trace ---

    Server stack trace:
       at System.Net.Security.NegotiateStream.ProcessWrite(Byte[] buffer, Int32 offset, Int32 count, AsyncProtocolRequest asyncRequest)
       at System.Net.Security.NegotiateStream.Write(Byte[] buffer, Int32 offset, Int32 count)
       at System.Runtime.Remoting.Channels.ChunkedMemoryStream.WriteTo(Stream stream)
       at System.Runtime.Remoting.Channels.Tcp.TcpClientSocketHandler.GetRequestStream(IMessage msg, Int32 contentLength, ITransportHeaders headers)
       at System.Runtime.Remoting.Channels.Tcp.TcpClientSocketHandler.SendRequest(IMessage msg, ITransportHeaders headers, Stream contentStream)
       at System.Runtime.Remoting.Channels.Tcp.TcpClientTransportSink.SendRequestWithRetry(IMessage msg, ITransportHeaders requestHeaders, Stream requestStream)
       at System.Runtime.Remoting.Channels.Tcp.TcpClientTransportSink.ProcessMessage(IMessage msg, ITransportHeaders requestHeaders, Stream requestStream, ITransportHeaders& responseHeaders, Stream& responseStream)
       at System.Runtime.Remoting.Channels.BinaryClientFormatterSink.SyncProcessMessage(IMessage msg)

    Exception rethrown at [0]:
       at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
       at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
       at Microsoft.VisualStudio.TestTools.Execution.IControllerAccessManager.GetControllerObject()
       at Microsoft.VisualStudio.TestTools.ConfigCore.TestControllerHelper.CreateControllerObject(String controllerUri)
    I, 2010/09/12, 18:47:57.759, Configured TFS Team Project Collection successfully.

    Do you have any idea what to do?

     

    /tony

     

    Sunday, September 12, 2010 4:58 PM

All replies

  • I think there might be an issue with the connection to the test controller most likely caused by a firewall or some DNS problems. Can you please do the follow tests to help narrow down your issue:

    Testing connectivity between test controller and client (machine on which Microsoft Test Manager runs):

    1. From the client machine, ping the test controller machine with its FQDN and with its bare host name.
    2. From the client machine, 'telnet <test_controller> <port>'. The default port is 6901.
    3. From the test controller machine, ping the client machine with its FQDN and with its bare host name.

    If step 1 or 3 fails, it indicates a problem with your DNS. Step 2 could indicate problem with your firewall settings on test controller. If above tests succeed, try to ping the TFS machine from the test controller.

    Most likely, the issue has something to do with the connectivity and the above tests should help you figure it out. Please let me know if it worked or not.

    -Darshan

    Tuesday, September 14, 2010 1:29 PM
    Moderator
  • Hi Tony

    I hope you are able to get past this issue. Let us know if you have any additional questions.

    Thanks!

     


    Hariveer Singh | If a post appropriately answers your query, Click 'Mark as Answer'.
    Thursday, December 16, 2010 9:20 AM
    Moderator
  • I have the same issue and I have noted something which I think is causal. 

    First of all, it should be noted that this system has been functioning properly for the past few months and this problem has just developed over the past week or so. 

    I have already run through verification of port connectivity between the systems and I have also verified that the account credentials in question are in the proper administrator groups, which I expected given the fact that this system has been working previously.

    Here is the behavior that I think is at the root of the issue, although I have not descerned the reason for the behavior:

    In the Configure Test Controller form, in the "Specify the logon account for the test controller service" subsection I enter the account credentials which I have verified exist and are valid, and then I click on the "Test" link to verify the credentials.  I receive the green checkmark which indicates success and then I click on the Apply Settings button.  The configuration process runs successfully and I close that window; I then click on the "Test" link again and now I am getting the red "X" which indicates failure. 

    For some reason the application seems to be removing the credentials when it is supposed to be applying them and the failed write operation from the original posters logs, which are mirrored in mine, indicate that there is a socket error that is preventing the system from saving the settings.

    Thoughts?

    Thursday, November 29, 2012 8:10 PM