CFMX7 Installation and Web Server Configuration Tool fails with JNDI ports blocked
ColdFusion Add commentsThis is a problem I have had a few times in the past, but last night was probably the most drastic action I have had to take so far to get it working. So I thought I would document the procedure, this is the cut down version as it actually took me 4+ hours to resolve the problem.
Client had ColdFusion MX 7 running fine for 2 weeks, then mysteriously it stopped working. Turns out the CFIDE folder had gone, so had all the JRUN connector files (<cfroot>/runtime/lib/wsconfig/1).
On attempting to re-install, the installer could not complete, reporting that ports may be blocked by a firewall or some other 3rd party application. This was of course not the case, as there was no firewall on the server.
The only part of the installation left to complete is the final part where the connectors are created and you open the CFADMIN, the ODBC services are created, and the final CF site of the setup occurs.
So I tried to create the connectors using WSCONFIG, and got this error (the same one showing in the logs as well)
Could not connect to any Jrun/ColdFusion servers on host localhost.
Possible causes:
Server not running
-Start Macromedia JRun4 or ColdFusion MX server
Server running
-JNDI listen port in jndi.properties blocked by TCP/IP filtering or firewall on server
-host restriction in security.properties blocking communications with server
So I use "netstat -an" command to see what ports are open and listening.
The JNDI port 2920 was there, but the proxyservice port 51011 was not, indicating that it is not open and listening.
So I opened the <cf-root>\runtime\servers\coldfusion\SERVER-INF\web.xml file and changed the default proxyservice port. See code below.
Change "deactivated" to false
Change "port" to a new value of your choice
<service class="jrun.servlet.jrpp.JRunProxyService" name="ProxyService">
<attribute name="activeHandlerThreads">8</attribute>
<attribute name="minHandlerThreads">1</attribute>
<attribute name="maxHandlerThreads">1000</attribute>
<attribute name="mapCheck">0</attribute>
<attribute name="threadWaitTimeout">300</attribute>
<attribute name="backlog">500</attribute>
<attribute name="deactivated">true</attribute>
<attribute name="interface">*</attribute>
<attribute name="port">51011</attribute>
<attribute name="timeout">300</attribute>
<!-- set this to false for multi-hosted sites -->
<attribute name="cacheRealPath">false</attribute>
<!--
<attribute name="keyStore">{jrun.rootdir}/lib/keystore</attribute>
<attribute name="keyStorePassword">changeit</attribute>
<attribute name="trustStore">{jrun.rootdir}/lib/trustStore</attribute>
<attribute name="socketFactoryName">jrun.servlet.jrpp.JRunProxySSLServerSocketFactory</attribute>
-->
</service>
The new port I had entered now showed up in netstat so I knew it was listening and not blocked.
WSCONFIG would still however not locate JRUN and connect to it. Then I found the below info over at brandon Purcell's blog , which I have slightly modified here to apply to a standard CFMX7 installation.
When wsconfig first runs it does a port scan from 2900-3000 to list any JRun servers that are running. In some cases it will hang when the port scan occurs. In the GUI this occurs when you click the add button. In the command line version it occurs when it searches for the servers and the prompt never returns. To test if this is the problem try the following commandwsconfig -host localhost -list (using the executable version)
C:\CFusionMX7\runtime\jre\bin\java -jar C:\CFusionMX\runtime\lib\wsconfig.jar -host localhost -list
This command should provide a listing of all running servers if it does not return to the command prompt and hangs then you can follow the procedure below
By narrowing the ports that are scanned by wsconfig you can prevent the hang. By default CFMX7 uses port 2920 for the jndi port. This port can be found in C:\CFusionMX7\runtime\servers\coldfusion\SERVER-INF\jndi.properties under the entry java.naming.provider.url=localhost:2920. If you are running multiple instances of JRun then you can look in each servers SERVER-INF\jndi.properties file for the range of jndi ports to scan.
To reduce the ports that are scanned use the following java arguments
-DWSConfig.PortScanStartPort=startport -DWSConfig.PortScanCount=portrange
So If I had 1 instance and the JNDI ports are 2920 then I would use the following command to list the jrun instances.
C:\CfusionMX7\runtime\jre\bin\java -DWSConfig.PortScanStartPort=2920 -DWSConfig.PortScanCount=1 -jar C:\JCFusionMX7\runtime\lib\wsconfig.jar -host localhost -list
To run the GUI and only scan those ports enter the following command:
C:\CFusionMX\runtime\jre\bin\java -DWSConfig.PortScanStartPort=2920 -DWSConfig.PortScanCount=1 -jar C:\CfusionMX7\runtime\lib\wsconfig.jar
Modify the ports to your range of JNDI ports and the GUI should work without hanging.
Here are a few other articles that can help with wsconfig debugging
http://www.macromedia.com/support/jrun/ts/documents/tn18287.htm
http://www.macromedia.com/support/coldfusion/ts/documents/connector_install_faq.htm
Nov 20, 2006 at 9:54 PM Russ you are a star! I have recently done a clean install of XP
but for some bizarre reason CF MX 7 will not install the web connectors.
While your solution didn't work exactly for me, it totally put me on the right direction - thank you.
The problem I had with your instructions is this path:
<cf-root>\runtime\servers\coldfusion\SERVER-INF\web.xml
This doesn't exist on my install. Instead I found the correct file (for me) to be:
<cf-root>\runtime\servers\coldfusion\SERVER-INF\jrun.xml
This contains the <service class="jrun.servlet.jrpp.JRunProxyService" name="ProxyService"> entry.
I simply changed <attribute name="deactivated">true</attribute> to <attribute name="deactivated">false</attribute>,
restarted CF server and low and behold the proxy server port was showing with netstat -an.
To sort the install out I then had to follow the manual instructions for installing the connectors here:
http://www.adobe.com/cfusion/knowledgebase/index.cfm?id=tn_19575
I am still at a total loss as to why this happens in the first place. Any ideas?
Thanks again for publishing this great blog entry and saving me from totally ripping my hair out.. :)
Nov 20, 2006 at 10:30 PM I think these problems are related to they way XP service pack 2 - now has an inbuilt "port scanner blocker". So basically coldfusion cannot complete its installation properly (thanks microsoft!!!). I had the sameish problem only the other week and used the method above to make the installation only look for port 2920 on JNDI side of things.
But I suppose that most installs of coldfusion would normally only be instaled on a proper server i.e UNIX or windows 2003 etc etc. XP isn't really a good choice.
Nov 20, 2006 at 10:30 PM In the case of my clients server, the recycle bin contained the majority of the missing files, so I concluded that someone who didn't know what they were doing had screwed things up, didn't admit it, and I was called in to clean up the mess.
If CF itself had somehow mysteriously deleted these files then i have no idea how or why this would happen. Is this what happened to you?
Nov 20, 2006 at 10:39 PM Ah I didn't read your post properly, the fact that you say your installing on XP makes a difference, and what Phil says is correct.
There are a number of factors that screw up installations on XP.
DEP (Data Execution Prevention)
XP firewall
Other security features of XP SP2
Sometimes disabling the XP firewall may be enough, but often not.
Sometimes disabling the DEP may be enough (http://www.zensoftware.co.uk/kb/article.aspx?id=10002), and sometimes not.
A good tool to use is filemon and sysmon from sysinternals, which will show you where access is being denied when something is trying to execute. But the primary factor with your problem, and also the other common problem with CF DSN's not being able to conenct to SQL server, is port blocking.
Mar 17, 2007 at 8:22 AM Russ,
Great job, very useful
Thank you vary mcuh, you saved my life.
Apr 18, 2007 at 3:45 PM Even though this is an old post, I just wanted to confirm and clarify the content of this post. I also wanted to offer my thanks. This got us out of a pickle.
Just to confirm, the same basic problem exists with Windows Server 2003 (SP1). The basic steps mentioned in this article apply to Windows Server 2003. Also, this is not a firewall issue. We do not have a local firewall enabled.
That said, there are a couple of mistakes. Someone already mentioned that the name of the file is jrun.xml, not web.xml. No biggie. Also, in our case, it was enough to change the "deactivated" to false. We did not have to change the port.
We created a new connector bat file called iis_connector_win2003.bat with the following command:
%CFUSION_HOME%\runtime\jre\bin\java.exe -DWSConfig.PortScanStartPort=2920 -DWSConfig.PortScanCount=5 -jar %CFUSION_HOME%\runtime\lib\wsconfig.jar -server coldfusion -ws IIS -site 0 -coldfusion -cfwebroot
We also created a batch file for testing the configuration and called it iis_connector_win2003_list.bat:
%CFUSION_HOME%\runtime\jre\bin\java.exe -DWSConfig.PortScanStartPort=2920 -DWSConfig.PortScanCount=5 -jar %CFUSION_HOME%\runtime\lib\wsconfig.jar -host localhost -list
Finally, when the connector runs successfully, you will see something like this:
Using C:\CFusionMX7\wwwroot for cfwebroot
Stopped "World Wide Web Publishing Service" service
Started "World Wide Web Publishing Service" service
The Internet Information Server (IIS) connector was installed to All
Again, thanks for posting this information. It was truly a help. I just wish MACR/ADBE would address this problem: this bug has survived since ColdFusion MX. I was really hoping to see that the connector issues were cleared up with ColdFusion MX 7.
Jun 19, 2007 at 1:42 PM The command line fix worked. Many many thanks! Bless you!
Aug 7, 2007 at 6:27 AM Thanks Russ. I've been racking my brain for over 4 hours on this with ColdFusion 8 on Win2k3. The command line worked great!
Apr 2, 2008 at 4:44 PM Well, I just ran the batch scripts and they both ran perfect. I haven't tested things yet, but I can see a switch was made.
thanks for the effort and help!