IIS 3

Perl can't run external commands.

Chances are, you've got something like: 
$var = `$cmd`; # backticks
or 
open(PIPE, "$cmd|");	# popen
@data = ;

You may also have noticed that the scripts run fine from the command-line, but not when invoked by the web server.

The problem here is that IIS runs processes without a console, and for some reason, this prevents Perl from redirecting I/O. You'll probably find that the external commands are running, but Perl is failing to receive output from them.

Under IIS2 and IIS3, the fix for this is quite simple: add the registry setting:

and set it to one. In other words, go to the Parameters directory in regedit, add a new value, of type REG_DWORD, and give it the name CreateProcessWithNewConsole. After creating the value, double-click on it to edit it to be "1".

Microsoft have changed this for IIS4, so check back here when you upgrade.

How do I enable SSI on IIS3?

IIS3 can support SSI include and exec directives, although you have to fiddle with things a bit. It also has two separate systems for SSI - native and extended.

Native support

This is the standard setting. It uses the two registry settings ServerSideIncludesEnabled and ServerSideIncludesExtension, in HKLM\SYSTEM\CurrentControlSet\Services\W3SVC\Parameter. You don't need to give the virtual directory execute permissions for this. It's limited, though, because it only supports #include.

Extended support

Extended support gives you #exec and the other common directives, as well as #include. This uses the ssinc.dll library that you get with ASP. To enable it:
  1. Make sure you've got ASP installed; the DLL won't be present otherwise.
  2. Don't worry about the registry settings described for native support; this DLL doesn't use them
  3. Create a Script Map entry to invoke the DLL. So in HKLM\SYSTEM\CurrentControlSet\Services\W3SVC\Parameters\Script Map, you have to create a REG_SZ entry for the extension you're using, and it should have C:\WINNT\SYSTEM32\INETSRV\SSINC.DLL as the value. You'll probably find that ASP.DLL is already mapped, which is the native support, so change it.
  4. Make sure that the files to be processed (and actually requested) are in a directory with execute permissions - this is necessary for anything to be processed by one of the Script Map entries.

Regarding both native and extended

Obviously, make sure that whatever you've specified as the file extension for SSI is the same as the files you want processed...

You can have both native and extended functionality enabled at once. If you configure both to use the same extension, then the extended (Script Map) version will be used, iff the requested file is in a directory with execute permission, and the native version will be used otherwise.

Can't run authenticated perl scripts from a link

This is where you've got protection on your page, and the script works fine if you go directly to the page and authenticate, but if you first authenticate on another page, then go to the script, the script seems to fail.

This is a bizarre one, to say the least. It was encountered by David Richoux, who describes his solution as follows:

We've got our problem solved in IIS 3.0. The solution? We drive the users through a "login" page which invokes a secured CGI program that is an executable rather than a Perl script. This appears to "set" the security context for the browser session so that all subsequent requests for secured pages and perl CGI programs work properly.
Steve Kilbane. Whitecrow home.