We have been having some severe problems this past month with FileNET’s Web services. When the user goes to the URL http://filenet.apps.******.com/ici_fnweb/home.asp they would get the following error message:
Whatever that means. We don’t have any Netscape products on our images. At any rate, from this specific problem we’ve derived an abstract solution to some IE problems. Try this – instead of creating a URL shortcut (i.e. “New Shortcut” and for the target put the web client page) try creating a shortcut to Internet Explorer (“C:\Program Files\Internet Explorer\iexplore.exe”) on the desktop. Then open the shortcut’s properties and add the URL to the end of the string, creating (in effect) a command-line argument. So your shortcut properties will have the following for its target (exactly as below, including the “” and the space in between:
“C:\Program Files\Internet Explorer\iexplore.exe” “http://filenet.apps.*****.com/ici_fnweb/home.asp”
As you might guess from the above, we still use IE 6. IE 7 is incompatible with FileNET’s web client (at least v. 3.3). However, it still may be useful for your purposes on another browser or version. If you find yourself having problems using particular pages, try creating a separate shortcut to IE and tacking the URL on to it as an argument.
The reason this works is that if you DON’T use this method, all your IE windows open under the same process. If there is a problem with one, they all kick the proverbial bucket. Any URL opened under this method will force it into a new instance of the ‘iexplore.exe’ process. It’s slightly harder on your system resources (barely), but it prevents some crashes (so that, when IE window A crashes, window B still stays open), and, at least in our case, provides relief from this false error message. I am excited to have made some progress on this, and I’m also excited to apply the same concept to a compatibility issue between Bizflow and Oracle.