IIS Answers ^tm                                                                                          
Support Central for Internet Information Server 4 and 5   

Ultimate IIS
hands-on, fast track, up-to-date training on IIS 4 and 5

IIS Lists
moderated email discussions on IIS related topics

About Brett Hill

Contact Information

IIS Administrator Newsletter
published by Windows 2000 magazine. See IIS Informant articles.

Installing PERL on IIS 4 or 5 is fairly straightforward. You can obtain a free version of Perl for IIS courtesy of the folks at www.activestate.com. We won't cover in this article why you might want to use Perl instead of ASP. I presuming that you've got a good reason or you wouldn't be interested.

On their website, it's hard to distinguish between the various offerings without reading everything. Here's a tip - what you need to begin with is the ActivePerl download.

Once downloaded, the installation program will take care of everything but there’s one catch. It only installs Perl to be active on the Default Website. Of course, this won’t do, you have to configure it manually for other sites. 

So, you can step through this procedure to install Perl for an individual site. Alternately, if perform this process on the WWW Master properties, Perl will be installed on any new site you create. Additionally, once you add Perl to the WWW Master properties, you can select to have the new configuration applied to the existing webs.

 First a few words about your choices of ways to run Perl and performance considerations. The ActivePerl download contains two ways. The third way you have to purchase from ActiveState.

 Choice #1 is to run parse your .pl or .cgi files through perl.exe. This is simple enough but has a significant performance consideration. Since IIS will call Perl.exe to process each request for a .cgi or .pl file, it creates a new, separate process for each file. This results in many separate processes running which consumes a lot of resources and make for very poor scaling. If you expect to have a popular site, this is not a good choice. It is however, easy and good while troubleshooting since it won’t crash your server if your script fails.

 Choice #2 is to call Perliis.dll to parse your Perl scripts instead of perl.exe. Perliis.dll is an ISAPI extension which means that it will run several times faster than Perl.exe. Furthermore, it will run as part of the Inetinfo (IIS) process which will give it the fastest possible execution. The downside to this is that it makes IIS vulnerable to being completely crashed by a faulty script since it runs as a part of the inetinfo process itself. Perliis.dll is also free and is included in the Activeperl download.

 There is another good headline to Perliis.dll. If you use it, you don’t have to give your application Execute permissions so in addition to it being significantly faster, it’s a bit more secure.

 Choice #3 is to pay for PerlEx which is ActiveState’s best performing offering. With PerlEx you get the ability to have perl script inline with HTML and perl interpreters stay resident in memory between calls. This gives quite a boost I’m sure to overall performance.

 So, having said all that, you have to choose which Perl is for you.

 Having choosen, you can proceed to implement Choice 1 or 2 as follows. I haven't installed PerlEx so I can't speak to that.

 Step 1: Create the “Application” 

Before you can link and executable such as perl.exe or perliis.dll with an extension like .cgi or .pl, you must define the web or virtual directory that contains the scripts as an “Application”.

 On the virtual web or master properties of the WWW service, select the Home Directory tab. (The Directory tab if you defining the Application on the Virtual Directory instead of the website. This is sometimes done to keep the area from which an executable can be launched to a minimum.) Push the Create button in the Application Settings part of the page. Optionally, type in a name for the Application. Now the Configure button will be enabled. If your have an Application already defined, no problem. 

 Step 2: Configure the Application.

 You will now be looking at the Application Configuration screen.

-         Click Add, this brings up the Add/Edit Extension Mapping window

-         In the Executable text box, browse to or type in the path to either perl.exe or perliis.dll. IMPORTANT! If you select perl.exe, include %s %s immediately after the path. (eg: c:\perl\bin\perl.exe %s %s). You application will NOT work if you don’t do this. Not required with perliis.dll.

-         In the Extensions box, type in the extension you want to map to the executable. Probably .cgi or .pl. Include the preceeding period.

-         In Exclusions box it is typical specify “put, delete” as http methods to reject in calls to the application.

-         If you are using perliis.dll, check the “script engine” box. This allows you to execute the dll without giving the application “execute” permissions.

-         If you are using perl.exe, the script engine box setting won’t matter as execute permissions are required.

 Step 3: Set permission on the Web or VD 

If you used perl.exe, set your Web or VD permissions to Execute. The setting “Run in a separate memory space” is not applicable in this situation since each instance of a cgi or pl page will load perl.exe in it’s own memory space.

 If you used perliis.dll, set your Web or VD permissions to Script.

 If you don’t need to Write to these locations, be sure to clear the Write checkbox of the “WebAccess” settings.

 Step 4: Set NTFS permissions on Perl.

 If Perl is installed in C:\perl\bin, you can set NFTS permissions to the IUSR account to simply Execute on the bin folder. My setup is Admins and System Full Control, IUSR Execute. I don’t have authenticated users or I’d have to include them too.

 Step 5: Set NTFS permissions on the scripts.

 Goto your scripts and mark them as NTFS special permission Read. The NTFS standard permission Read includes Execute which isn’t necessary and could be problematic if a user can get an executable into the folder. Particularly this is security concern if you are using Perl.exe since the application is also marked as execute.

 That's it!

You can find a test script to check your installation from KB article Q245225.