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
Related
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'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.
I've been happily using Team Foundation Server with Visual Studio 2010 for the last couple of months at my current place of work when it has suddenly stopped working. I get the following errors:
If I browse to the wiki (Sharepoint) on the TFS server it works fine in Firefox but in Internet Explorer it fails with:
No authority could be contacted for authentication.
I'm not aware of any changes to the server or my machine that would cause the errors and other users of TFS are not affected.
The TFS server is on a different domain to my machine, but usually I get prompted to login and using a domain prefixed username works. At the moment, I don't even get a login prompt anymore.
How do I fix this?
I have recently started to experience a similar issue. We also host TFS on a different domain. Twice in the last week TFS has stopped authenticating users, and I have received messages similar to above. I have no idea what is causing this, but on each occasion SQL Server Agent service was stopped. A reboot of the server and a manual restart of SQL Server agent seems to fix the problem temporarily. I'm not sure if this information is helpful, but I would also really appreciate any help in getting to the bottom of this.
We used a workaround to get past this problem. We configured an entry in the Windows Stored User Names and Passwords tool for the domain of the TFS server. It got around the problem of TFS not prompting for credentials by explicitly supplying them via this tool.
When you change your password for that domain account, you must also change the password here otherwise your account can be locked after failing authentication too many times.
I had the same problem, sorted it by upgrading to tfs2012
In my case, I changed the default port 8080 to port 80 and everything worked fine. but the message could also happen due to wrong saved credentials. you can go to the control panel of the windows and search for credentials manager and then remove your TFS credentials.
I'm testing a ClickOnce application deployment. I have setup a virtual directory on my machine (running IIS). I have specified http://localhost/SampleApplication as the Installation Folder URL in the Publish tab of Visual Studio. However, when I publish the application I get the following error:
Warning: Files could not be downloaded
from http://chrish/SampleApplication/.
The remote server returned an error:
(407) Proxy Authentication Required.
Publish success.
Warning: Unable to
view published application at
http://chrish/SampleApplication/publish.htm.
http://chrish/SampleApplication/publish.htm
Notice how it has changed my url from Localhost to my login name. Why? This wasn't happening a week ago.
ClickOnce installation involves verifying that the server name matches the expected name. Thus localhost always gets translated under the covers to the computer name [not the username as you suggest in your question] (one of many confusing things ClickOnce does - one side effect of this is that if you want to set up 3 download servers, you need to do 3 separate publishes and/or script the publish like this) or like this. So this is not a surprise - it's always doing that under the covers.
The 407 error relates to proxy auth. This implies downloading is being diverted via a proxy such as Microsoft ISA Server. Have a look in your IE Internet Options Connections Proxy Settings and make sure its bypassing for local addresses [such as chrish].
The reason it's reporting success is that the upload likely uses an alternate mechanism than the verification does and isn't being routed via / blocked by the proxy. (The underlying problem is that the .NET framework does not by default pass proxy credentials and you'd need to either apply a config entry for devenv or whatever does the publish or have the build process call a test step with extra code that does send the proxy credentials](http://blogs.msdn.com/jpsanders/archive/2009/03/24/httpwebrequest-webexcepton-the-remote-server-returned-an-error-407-proxy-authentication-required.aspx). See also How should I set the default proxy to use default credentials?)
ClickOnce doesn't like "localhost", but you can work around that.
If you set the Publishing Folder Location to:
C:\inetpub\wwwroot\SampleApplication\
and the Installation Folder URL to:
http://chrish/SampleApplication/
(where "chrish" is the network name of your computer) then you can publish locally.
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