I have two CF installations running on separate servers, CFMX7 on my 'production' development server and CF8 running on a secondary server I set up at the end of beta testing last summer. I was ready to make my primary server now CF8 as most of my new projects are developed in it.
Installing CF8 on the secondary server went flawlessly (except for forgetting uninstall Scorpio first). Prior installations of Coldfusion on my dev server also always occurred flawlessly. So, why then, when I attempted to install CF8 did I get a "JNDI listen port in jndi.properties blocked by TCP/IP filtering " error? What is the dickens was that? Java-ish in nature, I knew I was about to enter the netherworld of java...
(Sidenote, I would LOVE to take a few weeks off to learn the internals of CF, Java, RIA, FLEX, etc... but my project load is SO great, and coldfusion is SO good, I simply haven't had time. These are on my list of 100 things to do before I die)
I uninstalled CF8 figuring that was the issue and reinstalled 7... NOPE now CF7 throws the same error... grrr.
Checked the TCPIP of newly installed NIC card... oops, IP doesn't match IIS, so corrected.... but error remains (suspect this is root of problem)
I had just installed a new lan card, but for the love of mustard couldn't see why that would cause my Coldfusion to fail. But that indeed was the culprit.
Looking at Russ Michaels blog, who had a running client with the same issue in 2006, I ran
netstat -an to see what was listening (Thanks Russ... I would have never thought of that). Indeed there was not port 2930 listening on my netstat listing as is set up in \runtime\servers\coldfusion\SERVER-INF\jrun.xml.
so I looked at the server config and sure enough, my new card's IP was 192.xxx.xxx.4 instead of the 192.xxx.xxx.3 used in the IIS server setup. I corrected the card's IP address and could not get the system to look and listening (voila-- reboot).
Upon reboot, another netstat command shows that the tcpip port 2930 is now listening and the server will configure as it should. I could have updated the jrun.xml to another port that was listening, but this was more elegant, and I now have it set to what it was before.