Prologue: I am running windows Server 2008 R2 on a Virtual Machine. This virtual machine image has been happily hosting TeamCity on port 80 for several weeks. This TeamCity server is accessed by others on the network by visiting a url (pcname.domain.com).
The Issue: It seems corporate decided to push some updates to my machine over the weekend. It seems this round of updates decided to install/update IIS. Low and behold, visiting the URL mapped to the TeamCity server actually takes me to the stock IIS7 page. Visiting url/login.html brings me to the TeamCity log-in page.
Attempts: First off, I changed the TeamCity port to 8080 and was able to access it at url:8080 (or localhost:8080). However, it is imperative to me that people can access the server without providing a port... so I change TeamCity server port back to 80 and set off to try and fix this IIS problem.
Since then I have uninstalled IIS7 by removing the role and services from Windows - I am now hosting "0 roles". I have removed every trace of IIS from my PC, but visiting localhost still gives me 404 not found (instead of server not found or just my TeamCity page).
My Question: How do I prevent Windows Server 2008 from trying to host some default crap on port 80 so that my TeamCity server can be seen again?
EDIT: After performing netstat -ano, the only PIDs associated with port 80 are '0' and '4' (system and svchost!)
In windows the usual suspects using port 80 are IIS itself, and maybe the Web Deploy Agent Service if installed (but it could have any other app bound to that port). The PIDs 0 and 4 just tell you that the applciation using that port is running as a service. If you do not need any of this (IIS, web deploy, etc), go to Services and disable them, the port should be free to bind after that.
You can use net sh http show servicestate | findstr HTTP to reach the address and port binding information.
A simple solution (one that I am also using in a production server with multiple apps) is to set up a proxy based on either the domain or the URL path itself (see here how to with nginx).
Hit command, netstat -ano in an elevated command prompt to see what applications are listening on which ports. This command will show you the PID of the process that is listening on port 80. Now, open the Task Manager -> Processes tab. From the View -> Select Columns menu, enable the PID column, and you will see the name of all the processes those are listening on port 80. You can kill the listed tasks. Mostly applications like, World Wide Web Publishing service, IIS Admin Service, Web Deployment Agent Service may use the port 80 in Windows Operating System.
Related
I am managing a Windows Server 2016 Azure VM in the cloud that has IIS version 10 installed.
It currently has 2 sites that is live
Namely
http://www.clientdomain.com
http://portal.clientdomain.com
Both these sites work.
I need to setup a test site just for testing purposes.
I create 2 test sites in IIS and setup the bindings with hostname portal.clientdomain.com on port 88 and port 89 respectively in the IIS bindings.
I use a different port than 80,443 so it doesn't interfere with the live site
This works if I type in my browser
http://localhost:88 or https://localhost:89 on the VM directly
However, it needs to be accessible outside the VM on the internet.
For one or other reason I can't get the site url to open up in the browser.
Some of the URLs I have tried:
http://portal.clientdomain.com
http://sitename.westus.cloudapp.azure.com:88
http://TheIPAdress:88
http://clientdomain.com:88
which all the following cause the browser to gives the error This site cannot be reached with details The server took too long to respond
I tried various bindings too but nothing works.
My question:
Why does http://localhost:88,https://localhost:89,http://portal.clientdomain.com work directly on the server, however http://portal.clientdomain.com:88 or http://portal.clientdomain.com:89 do not if I made the bindings match. I also tried it with no bindings. Nothing works.
I have tried adding the ports to the Firewall as Inbound TCP rules but result is the same.
I tried to look for solutions and most of them talk about adding HTTP, RDP, HTTPS to security group which I have already done. I have a basic hello world nodeJS application running on Amazon Windows Server 2012. I want to access this application using DNS but it's showing ERR_CONNECTION_TIMED_OUT in my local laptop browser.
Configuration:
I have RDP, HTTPS, HTTP, SSH, Custom TCP Protocol with 9000 port (nodeJS is running on port 9000) for inbound rules and for outbound default "All traffic" rule is present. I have not done any changes in the Windows Server 2012 configuration. WHen I run localhost:9000 in the windows server 2012 then server returns "Hello World" but when I try that on my local machine with DNS : 9000 then it says ERR_CONNECTION_TIMED_OUT
Thanks for everyone's support. Special thanks to Viccari. His suggestion (in the comments below the question) worked. I needed to add the port to the firewall. So basically after adding all the protocols to the security group, I had to add the new port on which the NodeJS is working, to the firewall in the server. Finally its working.
We're re-writing our services from ASMX -> RESTful using ServiceStack so there's a short term need to keep IIS and classic services running on port 80. Also, some of our customers host more than one web app (e.g. company intranet) under IIS listening on port 80.
My application needs to be distributed to hundreds of customers, so I'd like to move away from the IIS dependency in the interest of making my deployment of updates simpler - if possible. We also have many customers who have setup special forwarding in their routers for port 80, so listening on a different port for SS services would cause a lot of deployment pain - not to mention most firewalls are more lenient with port 80 traffic.
I have two possible related issues:
1. When I can get SS to fire up on port 80, I get "handler not found" for routes that would otherwise work on another port.
2. While debugging (start / debug / stop / restart), eventually a listener registration appears to "stick" and I end up getting:
System.Net.HttpListenerException (0x80004005): Failed to listen on prefix 'http://*:80/' because it conflicts with an existing registration on the machine.
at System.Net.HttpListener.AddAllPrefixes()
at System.Net.HttpListener.Start()
at ServiceStack.WebHost.Endpoints.Support.HttpListenerBase.Start(String urlBase) in C:\src\ServiceStack\src\ServiceStack\WebHost.Endpoints\Support\HttpListenerBase.cs:line 122
at FieldCommService.FieldCommService.ConfigureServices() in e:\Development\Source\Hg\fieldcomm\src\Services\FieldCommService\FieldCommService.cs:line 305
at FieldCommService.FieldCommService.Startup() in e:\Development\Source\Hg\fieldcomm\src\Services\FieldCommService\FieldCommService.cs:line 84
I won't rule out hosting the service under IIS as a solution, I just prefer not to take on/continue to take on the configuration and deployment pain IIS comes with.
I have two questions:
1. Is listening on :80 as a self hosted service possible [with AppHostHttpListenerBase]?
2. In the intellisense for AppHostHttpListenerBase, it's noted that this class is designed to allow listening on port 80 next to IIS, but that "admin user privileges" are required. What does this imply under Windows running as a Service? An identity belonging to the Administrators group? Or simply "Local System"?
I have deployed the web application in my system using the integrated weblogic server in the jdeveloper 11 g.
But when I start the server and try to access the home page from another system using my ip , I am not getting the page.
Should I be doing any configuration for the same?
i would check to see if you can ping the ip successfully where the application is running from the other system. if ping is successful i would then check to see if you can telnet successfully to ip using the port jdeveloper is listening on. if ping or telnet is unsuccessful depending on your system you might want to check your firewall/iptable rules.
I'm using WebORB for .NET and I've had no problems with it running on its default port (2037) in my development environment.
When I deploy it to my staging environment and attempt to access it over the public internet, this port is blocked at many points along the way as it's an uncommon port, and I observe a red WebORB logo with the message "can not connect to messaging server" when I access the WebORB console.
Opening the port is a partial solution, but anyone accessing WebORB's applications will also need to ensure they're not blocking that port... so it's not really a proper solution.
I have managed to get WebORB running on port 443 (which is used for SSL, and therefore almost never blocked), but only if I have no other sites in IIS with a port 443 binding.
This is also unacceptable as I will eventually have another site on the same server with a port 443 binding.
So, my question is: is it possible to run WebORB on port 443 (or 80), when another site in IIS is also bound to that port?
Update following answer
I'm on Server 2008R2, and therefore IIS7.5, and I'd prefer to run my WebORB website in integrated mode. The instructions in the first article mention adding a wildcard script map for Isapi.dll - this will only be invoked in classic mode.
I've added all of the entries that the article suggests, and have configured my site to use port 80. There are other sites bound to port 80 in IIS.
When I navigate to the WebORB console, I'm observing the same behaviour I saw before adding the new RTMPT handlers - a red WebORB logo and no entries appearing in the "Messaging Server" panel. However, I do see the "Bad request, only RTMPT supported." message when navigating to ~/open/1, and my diagnostics.aspx page looks fine.
In the log I see the following:
...
WEBORB INFO:adding child scope for - \root
WEBORB INFO:scope registered - \root
WEBORB INFO:WebORB Messaging Server 4.4.0.0 (c) 2003-2010 Midnight Coders, Inc.
WEBORB INFO:is running - False
WEBORB EXCEPTION:System.Net.Sockets.SocketException (0x80004005): An attempt was made to access a socket in a way forbidden by its access permissions
at System.Net.Sockets.Socket.DoBind(EndPoint endPointSnapshot, SocketAddress socketAddress)
at System.Net.Sockets.Socket.Bind(EndPoint localEP)
at Weborb.Messaging.BaseRTMPServer.start()
WEBORB INFO:shutting down WebORB Message Server
WEBORB INFO:loading type: Weborb.Management.ServiceBrowser.Browser.AssemblyBrowser
...
Do I need to alter any other config to enable the console to use RTMPT?
Also, given that incoming requests must be over HTTP, is there no way to consider host headers?
what you are asking is whether you can route RTMP connections via port 80 or 443. Since these ports are managed by IIS, the incoming connections must be HTTP-based. Your RTMP clients can connect via port 80 or 443 by using RTMPT or RTMPS respectively. In that case, you do not need to "run WebORB on these ports", but instead configure WebORB to use RTMPT or RTMPS. Please see the following doc:
Configuring RTMPT in WebORB: http://www.themidnightcoders.com/fileadmin/docs/dotnet/v4/guide/rtmpt.htm
Configuring RTMPS in WebORB:
http://www.themidnightcoders.com/fileadmin/docs/dotnet/v4/guide/rtmps_support.htm
Hope this helps.
UPDATE: If the goal is to route the management console's traffic via RTMPT, it will not work with the currently released version. The console can dynamically determine the RTMP port, but it will stick to the RTMP protocol and does not have the code to switch to RTMPT. This is something we will look into.
As for the exception you're getting, it occurs because the port you specified in Global.asax is already taken by some other process.