So it's middle of the night, you are sitting at the customer's site trying to load test the production environment and need to quickly add a new test agent to the test rig to enable more concurrent users for your load test. No problem, you'd think, it's all described at https://msdn.microsoft.com/en-us/library/hh546459.aspx. So you follow the instructions there, double check all the settings, IP numbers, ports, firewalls, service accounts and their permissions and finally start the Microsoft Visual Studio Test Agent Configuration Tool to finish the configuration and add register the new agent with the controller.
You enter all the correct data, double check you entered the correct data, click on the "Apply Settings" and after all the fuss all you get is this exception in the log file:
So in this example 10.58.203.102:6901 is the correct IP address and the port number of the test controller you entered (and doublechecked) on the Test Agent Configuration Tool screen, but for some reason the agent ignores it and attempts to connect to itself at 127.0.0.1:6901. There's nothing on the agent listening at this port, thus the exception.
What's the problem you might ask.
The hosts file.
That's right, the hosts file. The guy at C:\Windows\System32\Drivers\etc.
You open this file and find something like this in it:
127.0.0.1 crl.microsoft.com
It's actually not important what URL was mapped to 127.0.0.1 there, as soon as you have ANY URL mapped to 127.0.0.1 in the hosts file you'll get the exception above.
Why? I have no idea. We used the IP and not name or the FQDN of the controller in the agent configuration, so it didn't have to do any DNS name resolution at all, but it did. And even then, our controller IP address was not mentioned anywhere in the hosts file, so go figure.
So how to solve it? Simply remove all the mappings for the 127.0.0.1 from the hosts file on the agent and try to register the agent again (restart the agent service to make sure it gets the new hosts file). It should connect now or at least bring some other exception.
And before you go - do the same on the test controller or you might get similar exceptions there.
You enter all the correct data, double check you entered the correct data, click on the "Apply Settings" and after all the fuss all you get is this exception in the log file:
I, 2015/05/27, 00:18:31.120, Getting
information about controller: 10.58.203.102:6901.
I, 2015/05/27, 00:18:31.120,
Creating Channel
I, 2015/05/27, 00:18:31.151,
CreateControllerObject : ControllerVersion : 12.0
I, 2015/05/27, 00:18:33.195,
CreateControllerObject: attempt 0, System.Net.Sockets.SocketException
(0x80004005): No connection could be made because the target machine actively
refused it 127.0.0.1:6901
Server stack trace:
at
System.Net.Sockets.Socket.DoConnect(EndPoint endPointSnapshot, SocketAddress
socketAddress)
at System.Net.Sockets.Socket.Connect(EndPoint
remoteEP)
at
System.Runtime.Remoting.Channels.RemoteConnection.CreateNewSocket(EndPoint
ipEndPoint)
at
System.Runtime.Remoting.Channels.RemoteConnection.CreateNewSocket()
at
System.Runtime.Remoting.Channels.RemoteConnection.GetSocket()
at
System.Runtime.Remoting.Channels.SocketCache.GetSocket(String
machinePortAndSid, Boolean openNew)
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)
What's the problem you might ask.
The hosts file.
That's right, the hosts file. The guy at C:\Windows\System32\Drivers\etc.
You open this file and find something like this in it:
127.0.0.1 crl.microsoft.com
It's actually not important what URL was mapped to 127.0.0.1 there, as soon as you have ANY URL mapped to 127.0.0.1 in the hosts file you'll get the exception above.
Why? I have no idea. We used the IP and not name or the FQDN of the controller in the agent configuration, so it didn't have to do any DNS name resolution at all, but it did. And even then, our controller IP address was not mentioned anywhere in the hosts file, so go figure.
So how to solve it? Simply remove all the mappings for the 127.0.0.1 from the hosts file on the agent and try to register the agent again (restart the agent service to make sure it gets the new hosts file). It should connect now or at least bring some other exception.
And before you go - do the same on the test controller or you might get similar exceptions there.
