Known Limitations and Workarounds, Web Server Support
|SE was working fine with IIS until after I applied a Microsoft Windows service pack. (Or it works fine on other machines but not this one) What's wrong ?
|The problem is that Microsoft Windows service packs, option packs, security patches etc... often effect more than just the operating system.
They often effect (directly or indirectly) other Microsoft software products installed on the machine.
Things such as Internet Explorer web browser, and IIS webserver (and hence any software that may be plugged into IIS).
Exactly how did your service pack effect IIS ?
Do you know ?
We sure don't know... only Microsoft knows this.
Microsoft service packs, option packs, security patches, etc... effect your operating system and other Microsoft software in unknown ways.
ServletExec installs/plugs-into a webserver (like IIS).
A webserver is just software.
Anytime you have 2 or more pieces of software working together, interacting... and you change something about one of the pieces of software, there is the potential that you will break the ability for the 2 or more pieces of software to work together.
That is just the nature of software.
So basically, this seems to us to be a classic:
"everything worked, and then I changed something, and now it doesn't work... what's wrong ?" problem.
For this type of problem, the answer is usually found by asking yourself:
"what did I change?... what is different between the time when it worked and the time that it stopped working ?"
If the answer is that you applied a Microsoft Windows service pack, option pack, or security patch, then it seems to us that it broke your IIS (or it's ability to use currently installed extensions such as SE ISAPI or SE AS).
We've had other customers report problems like this after applying a Microsoft service pack, option pack, or security patch.
They report various problems including:
IIS hangs, servlet/JSP requests hang, IIS won't stop, IIS won't start, etc...
For these customers we have recommended that they completely uninstall ServletExec and then reinstall it. In the case of SE ISAPI this has nearly always cleared up the problem.
The Microsoft IIS Lockdown tool (see SE FAQ #277 for more information) is another common culprit for this sort of problem.
It is our belief (due to customer reports) that running this tool is sure to break ServletExec's ability to function with IIS.
Various problems like the ones listed above can occur after applying this lockdown tool. Here are some details of customer reports related to this:
After applying the IIS Lockdown tool, SE ISAPI (or AS) would start up fine.
The ServletExec admin pages could be accessed (so GET requests to a servlet would still work). But trying to submit any of the forms on the SE Admin UI would fail with a 404 HTTP return code.
No errors would be found in any of ServletExec's log files or in DBMON.
The same behavior would still persist even after giving Everyone Full control over all of SE's folders and files (including ServletExec_ISAPI.dll or ServletExec_Adapter.dll), and even the JDK folders.
We believe the problem had to do with the fact that a POST request to SE's admin servlet typically causes that servlet to try to write changes to the appropriate ServletExec configuration file and the IIS lockdown tool was not allowing SE to write the file.
In fact IIS was somehow trying to be "smart" and disallow ServletExec to complete its task or even to output a stacktrace that might give a clue to the problem.
Based on that customer's problem description, we believe that IIS was somehow taking the request back from SE and quietly returning 404.
We had one customer report that they had a fresh Windows 2000 sp4 / IIS 5.0 installation on a brand new machine.
He said that his entire OS & software installation came from an "image"... meaning that the OS and IIS and
other "baseline" items along with all service packs etc, were copied onto the fresh hard-drive.
He told us that this image already had the IIS Lockdown tool in it.
He said that he was trying to install SE 4.1.1 AS against his IIS on the newly built machine.
He stated that if he installed with JDK 1.4.1, everything worked great, but his requirements would
not allow him to use that JDK. So he rebuilt the machine fresh again from the image, and tried installing
SE 4.1.1 AS with JDK 1.3.1_09. He found that when he did that, the SE installer did not create the
servletexec.properties file and requests for simple servlets such as /servlet/TestServlet would return 500 internal server error.
He was able to have his IIS serve a simple static hello.html file.
Nothing from FAQ #7 would help in any way.
He later got past this problem and here is how (in his words):
Good news. When I was installing JVM 1.3.1 I was installing in the default installation path which was a mistake, I changed this to C:\program files\JVM now SE runs fine.
And here was our email reply to him:
Thanks for letting us know that.
Where the JVM resides wouldn't typically matter so as long as your StartServletExec.bat and StopServletExec.bat files point to where it is.
I know that the default location for the JVM is usually something like:
There must be something special about the root of the "C" drive on that machine. Maybe some special file permission settings that are enforced by the IIS lockdown... something that was not allowing the JVM (and the SE AS instance running inside it) the permissions it needs to do what it must.
Anytime you run the SE ISAPI or SE AS installer against IIS (whether for the purpose of installing, OR for the purpose of uninstalling), and anytime you use the IIS management console (to view or edit website properties, or virtual directories or anything like that) the IIS Admin service will startup.
So you must keep checking to ensure that the IIS admin service is stopped, before uninstalling, after uninstalling, before installing, and after installing.
Even though you stopped it once, things that you do may cause it to start up again, so during the install or uninstall process be sure to heed the popup dialogs that say "make sure the IIS admin service is stopped before continuing".
Failing to do so, can sometimes cause your system to become hosed in a state where Add/Remove programs indicates that SE is no longer installed, but attempts to reinstall SE by running the SE ISAPI or SE AS installer indicate that it is still installed.
And if you have used the IIS Management Console after stopping the IIS admin service, you'll need to be sure to re-stop the IIS admin service before SE will work (before the SE Metabase filter will get loaded by IIS).
Also... the Services control panel in windows is notorious for showing you the incorrect state of a service.
In other words it will sometimes lie to you and tell you that a service is stopped when really it is running, or vice-versa.
To guard against this, close all services dialogs and open a fresh one each time you want to see if the IIS admin service is running or stopped.
Windows NT is especially buggy in this area (the area of displaying the state of a Windows service). Windows 2000 is more reliable with this, and the refresh button will often force it to tell you the truth, but it can still be buggy at times.
The information provided in the main body of this FAQ (above) is at least partly supported by information given at:
where it says:
Some programs seem to stop working after you install Windows XP Service Pack 2
SUMMARY: After you install Microsoft Windows XP Service Pack 2 (SP2), some programs may seem not to work. By default, Windows Firewall is enabled and blocks unsolicited connections to your computer. This article discusses how to make an exception and enable a program to run by adding it to the list of exceptions. This procedure permits the program to work as it did before the service pack was installed.
INTRODUCTION: To help provide security for your Windows XP SP2-based computer, Windows Firewall blocks unsolicited connections to your computer. However, sometimes you might want to make an exception and permit someone to connect to your computer.
After you install Windows XP SP2, client applications may not successfully receive data from a server. Following are some examples:
- An FTP client
- Multimedia streaming software
- New mail notifications in some e-mail programs
Alternatively, server applications that are running on a Windows XP SP2-based computer may not respond to client requests. Following are some examples:
- A Web server such as Internet Information Services (IIS)
- Remote Desktop
- File Sharing