I'm getting following errors on the test controller machine, when I'm trying to run CodedUI Tests remotely:
(QTController.exe, PID 3032, Thread 12)
ControllerDeployment.DoDeployment: System.Net.Sockets.SocketException
(0x80004005): No such host is known
During controller and agent configuration no errors came up. And when I go to Manage test controller dialog in Visual Studio I can see all the agents active. But when I try to execute any CodedUI test remotely it's hanging forever.
Not sure if it's connected with the fact that I've upgraded client/controller/agents to 2012 versions recently, but I've started seeing the problem only after this upgrade.
From Microsoft KB 2643086:
This issue occurs because the test agent computer sends its Network
Basic Input/Output System (NetBIOS) name instead of sending its Fully
Qualified Domain Name (FQDN) name to the test controller computer.
When the DNS server of the test controller computer does not have the
IP address mapping of the NetBIOS name of the test agent computer, the
issue that is described in the "Symptoms" section occurs.
You should ensure you are using fully qualified domain names (FQDN).
There is also a hotfix is available from Microsoft. However, you have to contact Microsoft Customer Support Services to obtain the hotfix.
I had similar problem, still not completely resolved but a workaround is to install Visual Studio on controller box and keeping result DB on same box.
Mostly the issue is restriction / firewall on VPN which might be blocking incoming traffic on TCP ports of machine / laptop.
Related
If I change the machine name of a Win2016 server (as a precursor to putting it on the domain) this causes the 'Default Website' in ISS v10 to fail.
I have not created any other website, virtual directory or AppPool. There are just the objects and settings that IIS creates when it is first installed.
As soon as I navigate to 'http://localhost' in a browser the 'DefaltAppPool' will stop and several errors will be generated in the 'Event Viewer' (from the 'WAS' source in the 'System' log and the 'IIS-W3SVC-WP' soruce in the 'Application' event log). These errors indicate the 'worker process failed to initalise and therefore could not be started'.
If I change the machine name back to the old name then the IIS appPool works as normal.
It suggest that the 'ApplicationPoolIdentity' is somehow hard-coded to a specific machine name.
I have also tested a Win2008 R2 VM with IIS v7 and the same issue occurs. I have also found this with another Win2016 VM that has never had IIS installed before.
It seems that even if IIS has never been installed before if the machine's name has been changed at any time IIS will not work.
Although I am familiar with IIS I am not an expert but I would expect that when I have installed IIS as a brand new role that the 'Default Website' and 'DefaultAppPool' that are created as standard should work without any further configuration.
Can you please advise how I can investigate / resolve this ?
============ Update 07-12-2018 =================
I have been doing some more testing and I think I may have found the trigger (although cause & resolution still unknown).
The original name of the unchanged Win2016 VM was 'WSVR2016-02016' and I tried changing the name (but keeping the VM in a workgroup) and after each change restarted the machine then when it came backup I made sure the IIS 'DefautlAppPool' was started in IIS Manager, visited "http://localhost" in the Chrome borwser and then checked the IIS Manager to see if the AppPool had stopped.
I tried each of the following names (all still in a Workgroup) and they all worked:
WSVR2016-O2018 |
WSVR2016-O2018T |
TEST-PAL-AD |
TEST-PAL-ADV2
I then tried changing the networking of the VM to Bridged rather than NAT but keeping the last machine name - still it worked.
I then tried, with the same 'TEST-PAL-ADV2' machine name, connecting the VM to our domain and when I went to 'http://localhost' the IIS AppPool stopped !
So it looks like connecting to the domain is what causes the problem - but how ?
(I did notice that each time I changed the machine name the name of the server retained the old name in IIS. So the top 'connection' node was saying "WSVR2016-02016 (TEST-PAL-ADV2\Administrator" - but it did the same through all the name changes and did not stop IIS working)
There may be settings or policies pushed out by the domain that are preventing the ApplicationPoolIdentity from running. I would suggest changing the DefaultAppPool pool to run as local system and inquire with your domain admins regarding any policies that might be interfering. You may also be able to discern some of that yourself by running gpresult
Issue: When running a load test from my client, with a remote controller on a second machine and a remote agent on a third machine, I receive the following error
Error 8/28/2017 6:59:18 AM Failed to queue test run '': No
such host is known.
I have Visual Studio 2017 on my client. The 2017 Test Controller is installed and configured on a second machine running Windows Server 2016. The 2017 Test Agent is installed and configured on a third machine running Windows Server 2016. The Test DB is on SQL Express on the second machine, same box as the Test Controller.
The configuration of all items worked fine (Test Controller, Test Agent, etc) without any issues or errors.
I installed VS 2017 on the Test Controller machine and was able to run tests without issue.
I can debug from my client without issue, but when I try RUNNING the test, it states the error above.
I can "manage test controllers" and see my controller, as well as the test agent listed, all in "ready status." Additionally, setting the LoadTest DB has a "test connection successful" message when setting it up.
My current .testsettings file is set up with the role to have all agents associated with my test controller be for running tests. It is set as the active test setting.
I've put the FQDN in all the setup, and added all the associated machines to the host files on each box.
The firewall has been disabled on every box to try that to no avail. Network Sharing is on, Printer sharing is on, ports are open. Verified this with port scanners, checking settings on the servers, and I can ping and NSLookUp each box from each other.
I've tried recording brand new tests and running existing tests (ones that worked if I ran VS2017 on the Test Controller) to no avail.
At this point, I'm really not sure what else to do or try, nor what other information to provide. I'm dumbfounded as I've read all the troubleshooting docs on network permissions, local permissions, etc. The only thing I haven't done is made an AD group for the machines involved and adding those to local admin groups.
If anyone could help, PLEASE, feel free to ask questions and I'll do my best to provide the info.
You can confirm these:
Create a load test in VS17.
On one computer, you configure a test controller in a domain.
On another computer, you configure a test agent in a different domain.
Note: The two domains trust one another.
You run the load test on the test controller computer and the test agent computer.
Edit:
Connect your controller computer and get its hostname.
Go to host file "C:\Windows\System32\drivers\etc".
And add hostname as IP address.
At last VS17 will successfully connected to your controller.
I had the same issue. The problem is that there was no route BACK to the client. I needed to add a fully qualified entry for the cient to the hosts file on the controller. This was compunded by using a VPN to Azure.
To clarify you need the FQDN of your client added to the hosts file of your controller.
I am receiving the error when trying to register a test agent to the load test controller
Configuration started on 2015/10/16, 16:05:47.
OS Version : Microsoft Windows NT 6.3.9600.0
Executable version : 12.0.21005.1
I, 2015/10/16, 16:06:07.812, Restarted service successfully.
I, 2015/10/16, 16:06:07.968, Verifying that the test agent is able to connect to the test controller.
E, 2015/10/16, 16:08:10.005, Test agent could not connect to the test controller.
I, 2015/10/16, 16:08:10.005, Disabling auto logon on the machine...
I, 2015/10/16, 16:08:10.005, Adding agent setting AutoLogonEnabledByAgentConfiguration=0 on agent machine
In the windows event log, this is seen:
Unable to connect to the controller on 'machinename:6901'. The server has rejected the client credentials.
The logon attempt failed
I've tried all I can find for people that have reported similar issues (Firewall is disabled, no antivirus, UAC is disabled, user is in admin group as well as TeamTestAgentService/ControllerAdmins/ControllerUsers). I've tried running the setup under different users/same user/"as admin" while still using the same username/pass for the log on. Trying to point different machines Test Agents to this controller and the same error occurs. Per another site, I also tried adding this to QTAgentService.exe.config
<appSettings>
<add key="BindTo" value="x.x.x.x"/>
</appSettings>
I have also tried using a different account for the Controller vs Test Agent. IE Both CtrlUser and TestUser are in the same groups listed above. As I understand it thought, this should work since they should be the same name/pass for Workgroup authentication.
I've referenced these pages among others and unless I've missed something, those solutions do not apply.
"Test Agent could not connect to the test controller" VS2012 Agents
VS2013 Test agent and controller not communicating
VS2013 Remote load test agent can't connect to controller
https://social.msdn.microsoft.com/Forums/en-US/59bc2270-37d9-4297-ac3f-e0da21d10a95/test-agent-could-not-connect-to-the-test-controller-vs2012-agents
Any thoughts/suggestions?
I was using a version downloaded by a prior employee that we have been using for CodedUI testing (12.0.21005.1). I downloaded the latest version (2013 Update 5) and after installing that, it worked with the same settings I was using before.
I have a .NET 4 webservice running on IIS Express 7.5 on a 2008 Server
the service runs fine for a couple of hours or even a day but after some time the process crashes with an error message failed to translate IP address + Hostname to Site Id which is displayed red in the console output.
I streamlined the applicationhost.config to only contain a single site and the binding is only to an ip address and localhost but no success.
I use this command line to start IISExpress
iisexpress.exe /config:c:\myconfig\applicationhost.config /site:mysite
First of all a solution for the error would be great but any information on how to optain more data for this error would also help. I already checked the eventlog but can't find anything.
Well, I upgraded to IISExpress 8 which runs stable now.
I did not know what caused this issue, but I belive it was somehow related to heavy load on the server since to often (but not exclusively) happend during a scheduled backup.
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