I got a question for a particular 3rd party software on IIS the other day.
I have been running VopMail 5.3 (vircom.com) on a Win2k IIS5 system since 2002 until yesterday when the server HD failed. I dumped the system to a standby server with Win2k3 IIS6 and was back up in about 30 minutes all except for the Web Admin Tool.
Per instructions I created the necessary website and gave the folders the necessary permissions R,W,Exec. I then added the webmailmgr.dll to the Web Service Extensions with Allow.
The instructions also recommend that the Enviroment variable PATH contain the path to the install folder where the rest of the dll's and exe's are so that the webmailmgr.dll can find them.
So now I have the Path, the folder permissions and I set the IIS access to Scripts and Executables as directed.
All I get is HTTP Error 500 - Internal server error.
This one is kicking my butt. (Vircom refused to help stating that the software is no longer supported.) So I am on my own and need a little help, please.
First, I hope you realize that this issue ultimately needs to be solved by the product's vendor. The company needs to provide the following information:
If the product is not supported on Windows Server 2003, then I hope that you accept my apologies that it would be rather unfair for me to be substitute product support for arbitrary applications.
I tried searching for the "instructions" you mentioned, but I did not find such information in any document on their website that contained the words "IIS" and "VOPMail". So, absent any official information/instructions, it is really hard to distinguish whether what you are trying to do is even possible, and if so, how.
From the documentation I did locate ( http://kbase.vircom.com/Kbase32/default.asp?id=765&Lang=1 ) as well as your descriptions, I can give the following generic advice:
I would never recommend running the entire web server as LocalSystem because that introduces an unnecessary security risk. You really do not want to run software that requires running as LocalSystem without good reason - and it looks like the newer web mail tool interface is in ASP.Net and do not require LocalSystem (it works with the default, secure Network Service identity). So, you may want to consider moving forward to a more secure solution that is supported by the vendor.