Entries Tagged as 'Windows'

How to fix Lucee 'Handler "BonCode-Tomcat-CFM-Handler" has a bad module "ManagedPipelineHandler" in its module list' Error.

Handler "BonCode-Tomcat-CFM-Handler" has a bad module "ManagedPipelineHandler" in its module listFor whatever reason IIS likes to set the default version of .NET on some versions of IIS to 2.0. This is generally rediculous since 4.0 has been around for some time and even when 4.0 is installed and working, MS will default to 2.0.

If you install Lucee server on to your windows server and get this error, there are several possible causes:

1) You need to use a more recent version of .NET for your application pool. The fix is to adjust your .NET application pool version to 4.0 (or above) for that site, then restart the pool. Once you do that, your Lucee install should work perfectly.

IIS Application Pool Switch from 2.0 to 4.0

2) You need to ensure that you have .NET Extensibility turned on in your IIS Install. In windows 7, this is what the window looks like:

Enable .NET Extensibility

3) You have a .NET version cconflict. You'll need to remove all versions of .NET from your machine and re-install Lucee to let the installer handle installing .NET.

Hope this helps!

The Latest mod_cfml Update is Actually Pretty Important

For those of you who may not follow these things, users of the open-source CFML context creation software known as "mod_cfml" should know that the latest release is actually pretty important with regards to security. The mod_cfml software is a group of programs that work together in order to automate the process of creating contexts within Tomcat. Usually the process of creating contexts is a manual job, which is accomplished by editing various configuration files in order to tell Tomcat where to find the files for specific sites, like this levitra web, and directories (or contexts) when Tomcat receives requests for them. The idea behind mod_cfml is to simplify server management, and make creating contexts in Tomcat happen automatically by passing off configuration information from Apache or IIS to Tomcat so a new context can be made if it doesn't exist yet. Pretty basic stuff.

ddosThe problem is that, before this latest release, this process of automating the context creation using mod_cfml could be exploited to create a Denial of Service attack on the system that is running mod_cfml. Using a specially crafted attack that is targeted at mod_cfml, an attacker could potentially issue multiple requests in rapid succession to a vulnerable system. This process would cause many contexts to be created simultaniously, and could potentially overload and/or crash the server.

The newest version of the mod_cfml Tomcat Valve corrects this problem by adding limitors to how quickly new contexts could be created, and how many contexts can be created within a single day time frame. These limitors protect users from the danger that previously existed and the possibility of a DoS attack that specifically targets this issue.

You can install the latest mod_cfml Tomcat valve by shutting down Tomcat, removing the mod_cfml Tomcat valve from the [tomcat]/lib/ directory, and dropping the latest mod_cfml Tomcat valve back into the [tomcat]/lib/ directory. Now, restart Tomcat and you're good to go. Documentation on adjusting the new limitors in the Tomcat valve can be found here:


Railo users who have installed Railo 4.0.3 or newer will already have the latest version of mod_cfml, and OpenBD installers version 3.0 and up will have the latest release. If you are running with an earlier release and haven't updated your mod_cfml Tomcat Valve, you should consider doing so.

How To Block Access to Railo 3/4 Administrators in IIS 7 (security)

We work a lot with Railo over at Vivio. Railo is an open-source CFML processing engine and offers it's users a built-in web-based "Administrator" for the server as a whole and for each web site that is configured to use it. This blog post will review a couple ways to secure those administrators from prying eyes. Yes, the administrators are password-protected by default, but adding the following will provide yet another layer of security for your sites.

Method One: IIS (site-specific)

The first security method we'll review will use the built-in access controls provided by IIS 7. I'll be using Windows 7 and the IIS Default Website. This method will need to be implemented on each separate site you want to secure.

Start out by going to your site's root directory. Since I'm using the "Default Site" in this example I'll go to C:\inetpub\wwwroot. From here, create an empty directory called "railo-context". The directory itself doesn't matter, only it's name and the permissions we will assign to it. In fact, once the rule is in place, you can actually DELETE the physical directory and the permission rule will remain in place in IIS. The rule is in the web.config for the site, so you can edit it there as well if you want.

Now that the directory has been created open the IIS Manager, and select the site that you're securing. You should see your new "railo-context" directory that you just created listed there:

railo-context directory in IIS 7

Next, make sure that the "railo-context" directory is selected and then hit the "Authentication" icon. If you do not see the "Authentication" icon, you will need to go to "programs and features" and make sure that feature is enabled for IIS.

select authentication in IIS

Now we're going to disable "Anonymous Authentication" in IIS. This is what allows interenet users to connect to our sites. Without this authentication enabled for our "railo-context" directory, visitors from the internet will not be able to connect to it.

disable anonymous authentication

Now lets test it. Looks like we're good to go!

iis permission denied


Method Two: BonCode Connector (server-wide)

The next method we'll review is securing the administrators by using the BonCode Connector. The BonCode Connector has been used by default since Railo 3.3.2, and is installed "globally" by default. This method will block access to the administrators by any connection made through the BonCode Connector - which is nice because you don't have to worry about it for every site you make. If you installed the BonCode connector on your own and did not install it globally, then you will need to configure the BonCode Connector by way of the site-specific config files in the BIN folder of each site. This negates some of the convenience of this method, but it still gets the job done.

Start out by opening a copy of Notepad as the administrator user. This will give you the permissions you need to edit the file. To do this, find the "Notepad" icon in the start menu and right-click it, then select "Open As Administrator". This will open notepad in administrator mode.

From there, if you installed the BonCode connector "globally", or if you installed Railo using a Railo Installer version 3.3.2 or greater, open the following file: C:\Windows\BonCodeAJP13.settings.

Once you have the file open, change the "EnableRemoteAdmin" value to "False", as illustrated below:

BonCode Connector Enable Remote Admin

Now restart IIS and try to hit the admin URL from a remote machine. Notice how hits from the local IP will pass through this method, but hits from a remote machine will get the "Access from remote not allowed" error message.

access from remote not allowed


It is important to remember that the Railo Administrators will still be available when you use the Tomcat web server on port 8888. To block access to that from remote machines, simply use the built-in Windows Firewall and restrict access to port 8888 to only local access.

Sunrise in Rift

I've been playing Rift a lot recently. I like the game. There is a lot to do, tons of options.. it's fun. While playing a new ranger, I happened to get these rather cool shots of the sunrise in Rift. Hope you like them too.

Rift Sunrise

Rift Sunrise

Rift Sunrise

How To Fix Windows Java Error 1723

Just recently I experienced a problem with both installing or uninstalling Java (the JRE) on a Windows 2003 system. I had to research this quite a bit and there were no clear answers anywhere, so I though I'd post here on how I was able to fix it. In my case, I was using Windows Server 2003 64-bit, but this should apply to other Windows versions as well.

Windows JRE Error 1723The error I was getting was as follows:

"Error 1723. There is a problem with this Windows Installer package. A DLL required for this install to complete could not be run. Contact your support personnel or package vendor."

This error is caused when you delete the JRE directory without running the uninstallation program. The reason this causes a problem is due to the registry entries that the installer creates when the JRE is installed. There is a DLL that the installer uses to make (and remove during an uninstall) the registry entries. Without this DLL, both the install and the uninstall will fail. This error may also prevent you from installing updated versions of the JRE to your system - which is a security risk.

You can find the path to the DLL that the installer (or uninstaller) is looking for in your Application log. You can get to your Application log (at least on a Windows Server 2003 system) by going to Start - Administrative Tools - Event Viewer, and then selecting Application from the list on the left.

Once you're looking at the Application log, find the error message generated from the "MSI Installer" (It's probably the most recent error there if you just encountered the error.) and bring it up. In the "Description" text area, you should be able to see where the installer or uninstaller was looking for the DLL file it needs. This is important because it will tell you how to fix it.

Finding the DLL

The FIX:

The Fix for this is to give the uninstaller what it wants, and replace the deleted DLL files with ones that can be used by the install/uninstall process to edit the registry, etc. For convenience, I've uploaded a bin zip file that can be used for this purpose.

DOWNLOAD: => bin.zip  (md5: b2594fa66d12a9e8fafb0a1ba3ca555f)

In my case above, you can see where I installed the JRE to the desktop (and then probably deleted it to remove the clutter). Only later, when I tried to install a new version, did it become a problem. So, I downloaded the above zip file, extracted it to my desktop, created a "jdk" directory and moved the "bin" folder inside it, then ran the uninstaller again. I got a few more errors about other files that couldn't be found, but the uninstaller worked and I was able to install an updated version like I wanted to afterwards.

So... the next time you install the JRE or JDK, remember that you can't delete it by hand without problems!

Hope this helps!