Cross Domain Connection Issues with Test Controller

Question

I am having trouble resolving a problem I have connecting a build agent with the test controller in a cross domain environment.  I have purged out the actual machine names, domain names, and IP addresses just in case that is a security concern. 
Situation is this:
All machines are running Visual Studio 2013
Test controller/agents are on Windows Server 2012 R2
Test controller is installed as stand-alone in order to be able to do load testing, as well as API and CodedUI.
Build definition in TFS kicks off the automation using testsettings file to point to build controller
Application under test uses resources in the ABC.XYZ domain.  Test agents need to be in ABC.XYZ in order to test application E2E.
TFS is in Main.corp.company.com domain.
Test controller is a dual-homed box in corp.company.com and ABC.XYZ domains.  It are accessible from Main using the corp.company.com NIC.
All our dual homed boxes are set up this way.  Dual homed with Main and ABC directly is considered a security violation.
From the dual homed box, logged in with my ABC credentials, I can access TFS in Main using my Main credentials.
Manually, I can successfully kick off a test run from a command line from a VM in ABC.
Build controller and build agents are in Main.corp.company.com.
Build controller can successfully connect to build agent, and build agent successfully builds the automation.
Build agent fails to connect to build controller:
Failed to queue test run 'buildagent@MachineOne 2014-08-12 12:35:34_Any CPU_Debug': No such host is known
I can ping the build controller from the test agent, and I can successfully query port 6901:
Querying target system called:
testcontroller.corp.company.com
Attempting to resolve name to IP address...
Name resolved to 10.10.10.111
TCP port 6901 (unknown service): LISTENING
Firewall is turned off on the test controller.  Even if it wasn’t, the relevant rules allowing port 6901 and File and Printer Sharing are created.
Local Security Policy | Security Options | Network access: Sharing & security model = classic
NETBIOS names of the test agents and build agent are set in the test controller’s hosts file (they were pingable without this anyway)
NETBIOS name of the test controller is set in the test agent’s hosts file (it was pingable without this anyway)
Tried both simple NETBIOS name and FSDN for test controller in testsettings file
Considering installing a build agent on the same machine as the test controller, but suspect that would just move my communication problem to build controller : build agent
Considering moving test controller to Main and making the four test agents dual-homed, but there is a concern to limit the number of dual-homed boxes, and also suspect that would again just move the communication problem.
I can use netstat to verify that the service is listening to port 6901 on both NICs:
TCP    0.0.0.0:6901           0.0.0.0:0              LISTENING       6536
TCP    [::]:6901              [::]:0                 LISTENING      
6536
(PID 6536 is the QTController.exe)
However the VSTTController.log only mentions listening to the ABC NIC.  Since the connection to the ABC test agents works, that makes sense.
When I open the testsettings file on my laptop in the Main domain and examine the server name, there is a warning that the host cannot be found.  When I open it on a VM in the ABC domain I am able to manage the test controller and view all the test
agents.  However, if I try to restart the build controller I get an access denied error.  Not sure if that is related in some way.
I am using a ABC domain service account to run the test agent sevice.  There is a Main domain service account running the build.  Both service accounts are administrators on the test controller and in the TeatTestControllerAdmins and TeatTestControllerUsers
groups.  The test agent service account is also in the TeamTestAgentService group.
I tried to create a port proxy to forward requests from the Main facing NIC to the port on the ABC facing NIC:
netsh interface portproxy add v4tov4 listenport=6901 listenaddress=10.10.10.111 connectport=6901 connectaddress=10.20.20.222
This almost worked.  I could see with netstat commands that the port was opened and a connection was established with the build agent,  however after a long wait it hit an error that it couldn’t find the ABC NIC:
A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond 10.20.20.222:6901
So apparently the ABC IP is getting forwarded back to the test agent, which then of course can’t use it.
I am running out of ideas to try.  Not sure where the problem is:
Cross-domain issue between Main.corp.company.com and corp.company.com?  Or,
Problem with the test controller not being able to listen on more than one NIC?
I know I am not the first person to try to set up something cross domain.  Most of the troubleshooting suggestions I have been able to bing have been about fixing connections between test controller and test agents, which isn’t the problem here. 
Is this set up just so far from standard that VS can’t handle it?
Thanks in advance,
Gary

Answer 1

Hi Gary,
Thank you for posting in the MSDN forum.
>> Build agent fails to connect to build controller: Failed to queue test run 'buildagent@MachineOne 2014-08-12 12:35:34_Any CPU_Debug': No such host is known
>> I know I am not the first person to try to set up something cross domain.  Most of the troubleshooting suggestions I have been able to bing have been about fixing connections between test controller and test
agents, which isn’t the problem here. 
Just to make this issue clearly, you mean that it is not the Test Controller and Test Agent issue, am I right?
As you said that it is related to the Build controller and build Agent, am I right?
If it is related to the Build Controller and Build Agent, I suggest you post this issue to the TFS forum, there you would get dedicated support.
http://social.msdn.microsoft.com/Forums/vstudio/en-US/home?category=vstfs&filter=alltypes&sort=lastpostdesc
If there's any concern, please feel free to let me know.
Sincerely,
We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place. <br/> Click <a
href="http://support.microsoft.com/common/survey.aspx?showpage=1&scid=sw%3Ben%3B3559&theme=tech"> HERE</a> to participate the survey.