Configuring Multiple Weblogic IIS Plug-Ins On Same IIS Server

As some of you may know, I’ve been working on a deployment of BEA Weblogic these past couple of weeks. We were doing some testing today and found an interesting side effect that was positively unexpected. Let me first say that the issues we encountered were with IIS configuration, not specifically with Weblogic. However, the issue wouldn’t have come up if we weren’t working on configuring the BEA-provided iisproxy.dll IIS plug-in.

Here’s the issue: We want to configure our production server to run two sites. The primary site is the production site and the secondary site is a staging site which we’re going to try to configure to behave exactly like production and have a configuration that matches production as well. So, we want to have two separate Weblogic Domains (that listen on different ports) and two separate IIS servers (that listen on separate ports). The desired configuration looks something like this:

The configuration required to connect IIS to Weblogic is a dll and some configuration in IIS plus an external configuration file (iisproxy.ini) that tells the iisproxy.dll plug-in where to locate the “back end” Weblogic server. This configuration is explained well in the Weblogic IIS Plug-In documentation. However, what you wouldn’t necessarily expect is that Windows’ IIS 6.0 (and 5.0, for that matter) default behavior causes you to only be able to load the information in one of the iisproxy.ini files. That means that you’ll only be able to connect to one of the Weblogic servers and no matter which IIS server you access, you’ll ultimately end up working with the same Weblogic server.

What surprised me was that if you define two different directories in IIS for the two different sites, place the proper configuration files in each one and configure each site per the instructions, you’ll only end up using one of the two Weblogic servers. This, we learned, has to do with IIS configuration and the fact that it loads ISAPI extensions one time per host (not per website) by default. If you want it to use separate, independent loads of the ISAPI extensions for each site, you need to change the default settings. The details are buried in the documentation (step #7), but as we learned, while the documentation says this is just for virtual hosting configurations, it also applies to our configuration (which doesn’t use virtual hosting). We also learned that the items in step #7 are more challenging in IIS 6.0 than in IIS 5.0.

For IIS 6.0, follow these steps to make the two changes necessary:

1. you must first go to IIS Manager and then right-click on the Web Sites folder and choose Properties.
2. Then navigate to the Service tab and choose the checkbox next to “Run WWW service in IIS 5.0 isolation mode”. Click OK back to the IIS Manager.
   
3. Next, go to the production website within the Web Sites folder and right-click to access the properties.
4. Navigate to the Home Directory tab and near the bottom, choose High (isolation) in the Application Protection pulldown at the bottom of the panel.
5. Follow the steps to make the same change for the stage website as well.
6. For good measure, I restarted both the websites and the Web Publishing Service in Windows Services Control Panel.

That’s it. If you have suggestions or alternatives to this process, feel free to post in comments.

Thanks to Keyur and Prashasta for their help identifying the solution to this issue!