Why do I need to run the Web Configuration Tool?

[ACS LLC]

While working through my migration from Windows Server 2008 to Windows Server 2016 (clean install) I came across a problem, none of my CFM files would load, I just got a 404 error.

I was running IIS, my root was the default innetpub/wwwroot for the CF2016 install, but my web sites are in another directory.

When I installed my 2008 server some time ago everything went fine. I did recently notice the two mappings for CF_scripts and Jakarta, and wondered where they came from. I'm pretty sure CF was installed and then I went to IIS to add my sites.

This time things were different, after pulling my hair out for an hour or two I realized that those mappings were not present. I ran the Web Site Configuration Tool, removing the ALL setting and then putting it back, and all of the mappings were now present and the sites were now working fine.

The question I have is, why am I now having to run this when I didn't have to do it before and does this mean I'll need to run it every time I add a new site?

Is there anything I can/should do when installing the IIS or ColdFusion so I can forget about this issue in the future and make it work when I just add a site in IIS?

Thanks

Mark

[Charlie Arehart · Accepted solution]

Mark, it's a simple problem on one hand, but definitely confuses people.

To answer your last question, you can just add the jakarta virtual directory yourself. You don't necessarily NEED to run the wsconfig tool.

The CF installer has always offered the option to configure the connection to IIS (or Apache) near the end of the installation process, or you could run the wsconfig tool at any time. Both options let one configure either "all sites" or individual sites.

And in CF10 and above, that does 3 things in IIS: it creates an ISAPI filter, several handler mapppings, and a jakarta virtual directory. These all point to a folder created in the CF config/wsconfig folder. If it's configured for "all sites", then the ISAPI Filter and Handler mappings are configured at the IIS "server" level and can be inherited by any new sites (as was the case in CF9 and before).

The problem is that IIS has no means to create auto-create the jakarta virtual directory. That's why you find things "not working".

So again, you can just add the vd yourself (especially in a case where you have only configured "all sites" to be connected to CF, as there is only 1 folder under config/wsconfig to point to). Or you can re-run the wsconfig if you want to. In the case of such an "all sites" setup, then yes, as you note it will remove the settings (and the VD from all sites), and then it will add them back to all sites PRESENT THEN.

And to be clear, all this also adds not just the jakarta VD but also the CFIDE vd (in CF 10 and 11) or the cf_scripts folder in CF2016 or 18.

(And if one wants to create a new connector for one or more sites, then you would run the wsconfig tool to create that connector for each additional individual site. And CF2016 even added a new feature in the wsconfig tool to configure EACH then-existing to use its own connector. Discussing that choice is beyond the scope of your question.)

Does that make more sense now? Any remaining questions?

[ACS LLC]

Thanks for the in-depth reply Charlie.

What I can't understand is why I never ran into this problem when I set up my previous 2008 server. I can only think that I either added the sites to IIS before I installed CF, or I did an upgrade over the top of my CF8 and therefore the sites were already in IIS, I just can't for the life of me remember.

I do always select IIS on the CF install, so I guess that it seems that every time I add a new site I must remember to either manually add the Jakarta virtual directory, or re-run the Web Configuration tool?

[Charlie Arehart]

Again, yes to both paragraphs.

[ACS LLC]

Something odd is going on. I ran the web config tool, and all is well, the sites were working fine. All of a sudden they stopped working. 'Connection reset'. No CFM files will come up, it'll serve HTML, and HTM but not CFM, I didn't change anything I was testing a site and all of a sudden this issue came up

I can't see anything wrong, the virtual directories are there. The CF administrator also works.

Any ideas?

[Dave Watts]

This isn't going to seem very helpful, but on the occasions where this has happened to me, I sometimes am able to get it going again by stopping IIS and CF, then starting CF, waiting a bit, then starting IIS.

It is possible to have the connector do its own logging, too. You can control that when you set it up. It's easy enough to set up and tear down, so you might try that.

Finally, make sure that the connectors being used are consistent for each site. In other words, check both the filters and the handler mappings for each site and make sure they're using the same connector directory number.

Dave Watts, Fig Leaf Software

[ACS LLC]

I've tried some stop/starts on IIS, I also ran the web configurator again, removed everything and then readded using add ALL, still the same problem. It's bizarre I was literally using the site giving it a test and then it just stopped for no apparent reason.

I've been running CF2016 on Win 2008 with absolutely no problems, but moving to 2016 has proved to be a real challenge, and I've been having all sorts of stability issues.

Oh wait, I found an issue while tapping this out. I have the site under a load balancer and I have RDPGuard on the server to monitor for brute force attacks. In my ISP dashboard I noticed that the port 80 was critical/blocked. RDPGuard had blocked it due to multiple attempts to RDP into the server which is odd because all the port to RDP is blocked on a firewall before it even gets to my server. The interesting thing is it's my ISP's IP, never had this problem on my 2008 server, so it's a strange one. I'll have to talk to them, and turn off the RDPguard for the time being. I'm accessing the server through KVM so no need to open ports to the RDP.

I can only presume that the CFM was coming from the server, but the HTM and HTML that I thought were working were actually in my browser cache

[ACS LLC]

To add to the above nightmare. I think I found the root of this. I have a drive mapped to my old server that allows me to move all the files to the new one. I see in the event log that there are security warnings (the RDPguard used to block the IP, which ended up being the servers own IP!). I see that it was a failed connection from the user name on the old server. The servers have different passwords and I THINK that the old server was trying to connect to the new server and it was tripping these errors. Although the IP would not be the same, so that might not make total sense when I think about it, but I think I'm looking in the right area.

I'm going to monitor the logs with the RDPGuard off, see how often it happens then power down that server and disconnect the network drive.

[Charlie Arehart]

Mark, how did things sort out? Was that indeed the problem?

[ACS LLC]

RDPGuard had blocked the IP of the server itself, therefore stopping it serving pages. I thought it was just CFM because other HTML files that I had tested were in the browser cache, it was in-fact all pages not being served.

The reason for this was that I had imported settings for CF from my old server, there were some scheduled tasks running and they were using the original servers user name and password for authentication. As these scheduled tasks ran they cause authentication failures, therefore RDPGuard blocked the IP, which was the IP of itself, therefore blocking port 80.

With regards to running the web configurator, I'll never know for sure but I can only presume that in the past I must have set up the domains in IIS before I installed CF (which I don't remember or think I would do) and then on install CF puts in all the mapping. This time I must have installed CF first, then added the sites, hence the missing mappings which the configurator fixes. CF2016 is new to me, so parts CF8 didn't have the same sort of configuration/issue, I've noticed these mappings in CF8, so I think that is potentially part of the issue.

From now on when I add a domain I'll just make sure I run the CF web configurator after I set it up in IIS.

Also, when I export and import settings from CF to set up a new server, I'll make sure I stop all the scheduled tasks and ensure they have the right credentials for that particular server!

Lessons learned