Our IT dept restarted the server this morning. Our existing site went down because of an issue with the ColdFusion [CF] server. CMS is not going through CF as of yet.
CMS, CF and IIS are all on this same server.
Now, I can’t get to the log in page, [serverName]:9992. I get these errors: ‘Bad Request - Invalid Hostname’ and ‘HTTP Error 400. The request hostname is invalid’.
Is this a CMS, Apache, TomCat and/or IIS issue?
Any help would be greatly appreciated.
Can you connect to the machine which CM1 runs on directly (using RDC)? If so, can you attempt to load CM1 directly on that machine using “localhost:9992”? If you that works, this could be a networking issue.
And – apologies in advance if you’ve already attempted this (you probably have) – but have you attempted to shutdown and start CM1 back up since your IT team restarted the server?
No. I can not connect. And, no apologies needed. Save them for the future. And yes, I have attempted shutdown and start.
Right now, I’m looking at the server log from the time ColdFusion shutdown to see if anything is connected there. I’m waiting to hear back from IT as to when the web server was restarted to look at the logs from that point.
I’ll let you know if I find something or if I have more questions.
I’ve reopened our previous support ticket to request your server log. From looking at that, I should be able to identify pretty quickly if this issue lies with CM1, or rather if it’s some networking error.
To recap, the problem here was that a system misconfiguration was causing IIS to tie up CM1’s main port, 9992. Once we confirmed that this was not another case of a duplicate CM1 startup, we looked into what else might be using port 9992 on the server.
To root out this type of issue on a Windows server, you can run this from a command line:
netstat -a -n -o
This will list out all of the ports in use on the machine, along with their corresponding process IDs (PID). Once you find the PID that is using 9992, you can run:
tasklist /svc /FI “PID eq XXX”
Where “XXX” = the correct PID identified using the previous command. This give you the process / service name of the application that is using the port. Once you know exactly what is tying up the port, it’s simply a matter of reconfiguring or disabling the offending application.