IIS 6.0 CGI

[Dave]

Thx Ken (quick response!),

Although step b is not that clear to me, it seems like one of the many
things I tried... and it does not work for me.

The only way I can get 1 ".exe" file to work is the following:

Home directory -> Configuration -> Add an appplication extension
and point it on 1 ".exe" file.

This works, but as I understand, I just set all ".exe" calls to point to
one ".exe" file.
(I have tested my ".exe" files this way).

Also, should the "Allow ALL unknown CGI Extensions" work?
(In the Web Service Extensions that you have mentionned).

All permissions are set to everyone full control (test environment).

Thanks again!
Have a good day!

"Ken Schaefer" <kenR...@THISadOpenStatic.com> wrote in message
news:%23JyUsWl...@TK2MSFTNGP11.phx.gbl...
> a) Add a new Web Service Extension
> b) In the folder that the .exe is in, change Execute permission to
"Scripts
> and Executables"
> c) For the NTFS permissions, ensure that the impersonated user account has
> "RX" permissions.
>
> Cheers
> Ken
>
> "Dave" <dave...@hotmail.com> wrote in message
> news:9Ydac.9$fa1.3...@news.nnrp.ca...
> : Hi,
> :
> : Just started using IIS 6.0.
> :
> : Have been through and memorized ALL help files... :-)
> :
> : Could anyone out here tell me just one thing:
> : I want to run some ".exe" files. Have not found how.
> : (I've been all around and set all kinds of permissions,
> : I can't get more than 1 to work at a time).
> :
> : TIA
> : Dave.

[David Wang [Msft]]

What you are doing is incorrect. Repeating what Ken said, this is how you
allow C:\Scripts\FOO.EXE and C:\Scripts\BAR.EXE to run on IIS (and no other
EXE) from the /Scripts virtual directory.

1. Configure /Scripts vdir pointing to C:\Scripts with Execute Permissions
set to "Scripts and Executables"
2. Add a Web Service Extension via the UI, selecting both C:\Scripts\FOO.EXE
and C:\Scripts\BAR.EXE. Enable the Web Service Extension
3. Make sure that the remote authenticated user actually has Read/Execute
NTFS permissions on both C:\Scripts\FOO.EXE and C:\Scripts\BAR.EXE

Now, any request to http://localhost/Scripts/FOO.EXE will execute FOO.EXE
on the server.

Note: You do not need to do anything with "Allow ALL unknown CGI Extensions"
nor do you need to create an Application Extension mapping for .EXE. Those
are both incorrect things to do for your stated purpose.

On IIS6, with Web Service Extensions, it is possible to control CGI/ISAPI
execution down to the actual file itself. Thus, it is possible to setup
"allow all EXE to execute except FOO.EXE and BAR.EXE" or "allow no EXE to
execute except for FOO.EXE and BAR.EXE".

IIS and Web Serving is really just a bunch of straight-forward rules:
1. IIS6 does not allow content to be downloaded unless the extension of the
resource maps to an existing MIME Type
2. IIS6 does not allow scripts (ASP, ASPX, PL, PHP) to execute on the server
unless an Application Extension exists for that file extension AND the
binary script engine associated with the Application Extension is enabled by
some Web Service Extension entry
3. IIS6 does not allow binaries(ISAPI or CGI) to be executed on the server
unless that ISAPI or CGI is enabled by some Web Service Extension entry

Failure to have a MIME Type mapped for the resource attempted to be
downloaded results in a 404 response and a 404.3 logged in the web logs

Failure to have an Application Extension for an extension causes IIS to
treat the resource as static content instead of a script, and the rules for
MIME Type kick in.

Failure to have a Web Service Extension defined for a binary being executed,
either directly via the URL or indirectly as a script engine of an
Application Extension mapping, results in a 404 response and a 404.2 logged
in the web logs

Failure to have at least "Scripts" execution permissions while requesting a
script or "Scripts and Executables" execution permissions while requesting
an ISAPI/CGI causes a 403.1 response.

--
//David
IIS
This posting is provided "AS IS" with no warranties, and confers no rights.
//

"Dave" <dave...@hotmail.com> wrote in message

news:D6xcc.130$9a.94...@news.nnrp.ca...

[Dave]

Thank you David.

Now I get an "Internal Server Error 500".

I know the scripts work. Tried them with the type mapping.

"David Wang [Msft]" <som...@online.microsoft.com> wrote in message
news:uhXpNCSH...@TK2MSFTNGP10.phx.gbl...

[David Wang [Msft]]

Wait a minute, are you referring to CGI EXE or CGI scripts.

As for troubleshooting 500 errors, look in the web log files for clues or
post the appropriate log lines.

I suspect that if you are seeing 500 errors from a CGI, you will need to
troubleshoot that yourself since the CGI is executing... and returning 500
for what arbitrary reason and unrelated to IIS.

--
//David
IIS
This posting is provided "AS IS" with no warranties, and confers no rights.
//
"Dave" <dave...@hotmail.com> wrote in message

news:g%ldc.184$lp3.10...@news.nnrp.ca...

[Straatvark]

I have more or less the same problem, with a Dot.Net variation.

I'm busy building a Win2003 IIS6 server and move applications from a
Win2000 box over to it.

I use a ISAPI dll to generate an image which is then served to a
client's browser. This was only possible on the Win2003 server by
creating a Web Service Extension for the myDLL.dll in a "scripts"
folder. All worked well.

Then I want to use/install/activate my Dot.Net (my Dot.Net app use the
ISAPI dll to show GIS/map images). That I got working by creating a
Web Service Extension for the "aspnet_isapi.dll" dll as well. My
Dot.Net code is working fine then.

BUT, the moment I add the Dot.Net, my ISAPI dll promps me to save
itself/the image that it creates. The Dot.Net code keep on working
fine... When I remove the Dot>net extension, the ISAPI dll works fine
again...

Any ideas/response please?

Gert