We figure someone somewhere would benefit from a solution, as socket
server only solutions are becoming an increasing problem as IT units
revise security configurations and request SSL transport through
firewalls.
The issue is to do with the permissions under which the com server is
executed when invoked from httpsrvr on IIS. If you encounter this
problem you must fix the permissions under component services for the
com server so that they match the permissions under which the
httpsrvr.dll is executed on your webserver. You do not need the
midas.dll or borland memory manager in the scripts directory (unlike
some of the suggestions we saw), but the scripts directory (assuming
you put the httpsrvr.dll in the scripts directory as is the default
borland config) must have execute scripts and executables enabled
under the IIS scripts virtual directory. I.e you only need the
httpsrvr.dll in that directory AND...(different versions of windows
may have slightly different ways of doing the following, but
essentially you are trying to open the "manage component services"
snap in):
1. Click Start, and then click Control Panel.
2. Double-click Administrative Tools, and then double-click Component
Services.
3. In the Component Services snap-in, expand Computers, expand My
Computer, and double-click DCOM Config.
4. In the right pane, locate the program by using its friendly name.
5. Right-click the program name, and then select Properties.
6. On the Security tab, in the Launch and Activation Permissions group
box, select Customize, and then click Edit.
7. If you are using the annonymous user account to access IIS for the
httpsrvr.dll, then add the anonymous user, usually "machine_name
\IUSR_machine_name" or whatever user id(s) you want to be able to
oaccess the com server via Twebconnect. Give local launch + local
activation, etc and other permissions as required by your use.
This will make the access denied problem disappear.
One final note - early in the process we recompiled the httpsrvr.dll
incase their was a version problem with some of the components in it.
I do not believe, however that this had any impact on the final
outcome.
Our associated comserver was compiled under D7.1 with the 2005 midas
dll and all other third party components updated to versions released
in 2008. The client uses the midaslib code set (which allows the
midas.dll to obe omitted from the client release), but again this is
irrelevant to the access denied error.
Regards
JB