Knowledge Is Power

Sections on this page:	Script Adjustments The Platform IIS Server Setup Server Parsing Server Software
Companion pages:	How To Use Your CGI-BIN About htaccess & XBitHack Trying Sun Solaris For Intel x86 Automate Cisco Device Monitoring Find Out About Bad Links To Your Websites Windows PPTP Clients with Cisco VPN Routers Setting Up a DMZ with Cisco Routers

If you want to add a bookmark for future reference;   for Netscape press Ctrl-D,   for Internet Explorer click here

If you simply want to see what adjustments may need to be made to a Perl script (including the Bestdam Logger script) so that it will run on a Windows IIS server, the first section below will tell you. If you want to know how to set up your own IIS Web server to run CGI/Perl scripts, the information a little further down the page will show you how to do that.

NOTE Always read the documentation for any script you plan to use to determine the level of support in the script for Windows IIS servers, and for instructions on how to modify that script to take advantage of that support.

Very few changes needed to be made to the Bestdam Logger script for use on a Windows IIS server. I would suspect that this is true for most CGI scripts when the IIS server has a Perl interpreter installed and a script directory properly configured.

IMPORTANT:   Version 3 of the Bestdam Logger script will only send e-mail on NT/2K servers that are running the freeware Blat e-mailer. If you don't have Blat installed the script will still work. Just set User Variable 8 to No (0) to disable the sending of e-mails.

Any script that sends out e-mails needs the path to a mailer program on your server that can handle piped input. (The path value is needed for the second user variable in the Bestdam Logger script.) If you're not using your own server, check with your hosting service provider to see if they have Blat installed and find out what the correct path is. They may also have a different Blat-type program you can use.

In typical Windows/DOS fashion, paths contain back-slash (\) characters. However, the back-slash means something different to Perl (it's the escape sequence character). As a result, whenever you enter a path for a Windows server directory into a Perl script, always use two back-slash characters for every one back-slash character in the path. What you should enter for the second variable in the Bestdam Logger script, would then be:
c:\\winnt\\system32\\blat.exe
Any CGI script that prints anything on a Web page (even a hit count) will have a print statement that prints out a content type header. This print statement is often near the top of a script but it doesn't have to be. It can be anywhere in the script. Such a print statement will look like this:
print "Content-type: text/html\n\n";
If you look on your Web page where the hit count, or whatever is supposed to be displayed on the page, should appear (where the SSI directive tag is placed) and you see these words:
Content-type: text/html
then you will need to comment out the content-type print statement. (It is on the third line of the Bestdam Logger script.) To comment out the line simply put a pound sign character (#) in front of it so the line looks like this:
#print "Content-type: text/html\n\n";
The very first line in most scripts is called the "shebang" line. It is the path to the Perl installation for UNIX servers. It looks like this:
#!/usr/local/bin/perl
It is not needed for Windows IIS servers. Because this line starts with a pound sign character (#) ActivePerl seems to treat it as a comment and ignores it. However, if you get an error message that refers to "Line 1" of the script, try removing the shebang line.

About the only other thing that will differ between running a script on a UNIX/Linux server and a Windows server is how script-generated e-mail is handled. As far as I know (and I have searched the Web looking), there is no way to "pipe" an e-mail message from a Perl script to the SMTP service on an IIS or Exchange server. That's where the Blat software comes in. Blat interfaces with the SMTP service and does accept piped input from Perl scripts. See the Server Software section below for information on setting up Blat.

Note:  Many scripts are written to send mail using Sendmail only. However, if you are comfortable modifying scripts, you could use the Blat statements in the snipet of Perl code given below in the Server Software section to replace the Sendmail code to get the script to work with Blat.

Top of page

There are literally thousands of free CGI scripts available on the Web and a lot more available for a small shareware fee. Having the ability to enhance your Web site through the use of these scripts is well worth the time and effort to set them up. If you're new to CGI scripts, check out our How To Use Your CGI-BIN page.

Microsft doesn't configure IIS to run CGI scripts out of the box. They want you to use ASP. The problem with that is that ASP is a language where the code is embedded in HTML pages. It doesn't lend itself to stand-alone script-type programs like Perl does (where the code is all in a self-contained file stored on the server). As a result, there aren't any free stand-alone ASP "programs" available, just code blocks that you have to copy/paste into your Web pages.

Setting up a Windows server running Internet Information Server as the Web server software to run CGI scripts is very easy. There are only four basic steps you need to perform, all of which are detailed on this page.

1. Install a Perl interpreter
2. Create and set up a special script directory for the CGI scripts
3. Set up IIS to use CGI scripts and parse .htm pages
4. Install an e-mail utility that will accept piped input (only if you are going to use scripts that send e-mail messages)

IIS 5 is set to parse Web pages looking for SSI directives by default. However, only pages with certain extensions will be parsed. If you want IIS to parse pages with other extensions, the procedure to set this up (as well as why you would want to set it up) is detailed in the Server Parsing section below.

The following Windows IIS configuration was used in the testing the Bestdam Logger script and in preparing this page:

• Windows 2000 Server
• Internet Information Server (IIS) 5
• "cgi-bin" virtual directory created
• ActivePerl Perl interpreter v5.8.4
• Blat e-mail sending utility v2.22
• IIS SMTP service running

ActivePerl is a free Windows Perl interpreter available from www.activestate.com. Your Web hosting service may not necessarily have ActivePerl installed, but they should have some sort of Perl interpreter installed since none comes with Windows and none is available from Microsoft. It doesn't matter who's Perl interpreter they have installed on their servers. The important point is they need to have one installed in order for you to use CGI scripts written in Perl (which most are).

Blat is a freeware utility for sending e-mail messages from scripts via IIS' SMTP service (or it can be configured to use a different SMTP mail server). The Blat home page is at www.blat.net

There are other Perl interpreters and e-mail utilities. However, confirming that the Bestdam Logger works with the above configuration will allow you to ask questions of your hosting service if you are unsure of their server configurations.

If you're using a hosting service they have probably set up their IIS servers with a directory for storing CGI and other script files. It may be called cgi-bin or cgi or whatever. If you setting up your own server, see the IIS Server Setup section below for instructions on how to set up a cgi-bin folder under IIS.

Top of page

If you're setting up your own Windows IIS server the first thing you need to do is install the ActivePerl interpreter. There's not much I can say about ActivePerl. Just download it from ActiveState, install it using all the defaults, and forget it. The installation seems to take care of everything interpreter-wise.

The perl.exe file is installed into c:\perl\bin and this is added to your system path. This is helpful because it allows you to check out Perl scripts before you try to execute them from a Web page.

Simply open up a DOS window and go into the sub-directory under cgi-bin where the script in question is located. Let's say for example the script is called myscript.pl. At the command prompt type in:
perl -c myscript.pl
The -c switch performs a syntax check. You'll either get a "syntax OK" message or errors listed. For a more stringent test use the -w switch in place of the -c switch. You can also execute the script directly by typing in:
perl myscript.pl

Next you'll need to create a cgi-bin directory. This involves two basic steps:

1. Create a directory on an NTFS volume to store your scripts
2. Create a virtual directory under the selected Website which points to the directory you created in Step 1

As for Step 1, just create a directory called /perl-scripts or /webscripts or even cgi-bin if you want. The important thing is that you DON'T create this directory under the /inetpub directory. If you create if off the root directory it'll be easy to find and you don't have to worry about a lot of inherited permissions problems. You don't have to set any NTFS permissions on this directory. The virtual directory setup takes care of that.

For Step 2 you have to use the Internet Service Manager.

• Open ISM and right-click on the Default Web Site and select New and then Virtual Directory to start the wizard.
  
  
• In the Alias field enter cgi-bin and click on the Next button.
  
  
• In the Directory field enter (or browse to) the full path to the directory you created in Step 1 above and click on the Next button.
  
  
• In the access permissions panel make sure that the following three items have check-marks next to them:
  
  

  • Read
  • Run scripts
  • Execute

  
  
  and click on Next and Finish buttons.

When you're done you should see the new cgi-bin virtual directory listed under the Default Web Site. Right-click on this new virtual directory and select Properties and you should have the following:

Top of page

Setting Up Pages

Some CGI scripts are "called" via SSI directive tags in HTML pages. The server has to "parse" (look through) these pages trying to find SSI directives.

So as not to bog down a server by forcing it to parse every HTML file it serves up looking for SSI directives, Web servers typically only look through certain HTML files. These files are identified by their extensions.

By default, IIS will only parse HTML files that have .shtm, .shtml, and .stm extensions.

This can pose a problem if you want to start adding SSI directive tags to long-established pages. These pages may have the more traditional extensions of .htm and .html and through time could be linked to by numerous other sites and indexed with their current extensions by various search engines. Changing the extensions to accommodate server parsing would cause a raft of 404 errors when people try to access these pages from existing links and search engine references.

Apache users can get around the above problem by using a .htaccess file. You don't even have to be a server admin to set one up. However, with IIS you do have to be a server admin, or at least an IIS admin, to get around the above problem. Let's say you want IIS to also parse all pages that have a .htm extension. Here's how:

• Right-click on the selected Web site and select Properties
• Click on the Home Directory tab
• Click on the Configuration button
  
  
• Scroll to the bottom of the list in the App Mappings tab and you'll see the HTML file extensions listed for pages that are parsed by default
  
  
• Highlight the entry for the .shtml extension and click on the Edit button and note the mapping properties
  
  
• Click on the Cancel button to close this window and click on the Add button to create a new mapping
• Simply duplicate the mapping properties you noted in the previous step but this time enter .htm in the Extension field and click on OK
  
  
• Repeat this procedure to add a mapping for pages with a .html extension using the same values used for the .htm extension

Setting Up Scripts

When you installed ActivePerl it put in an app mapping for Perl scripts with a .pl extension. However, many CGI scripts have a .cgi extension. You can use the same procedure you used above to add a mapping to the ActivePerl perl.exe file for the .cgi extension.

• Under the App Mappings tab click on the Add button
• In the Executable field enter the path to the perl.exe file followed by a space and the characters "%s"%s
  
  
• In the Extension field enter .cgi and enter the Limit to values shown
• Check the Check that file exists checkbox and click on OK

That's all there is to it. It's probably a good idea to restart the server, or at least the IIS service using the Services control panel, so that all your changes take affect.

Top of page

Blat

Last but not least is the mailer utility. This step isn't necessary if none of the scripts you plan to use send e-mails. Blat is called from the Bestdam Logger script, which is called from an SSI directive in an HTML file. A few things I noticed when working with Blat and I thought I'd pass them along.

When you extract the blat.zip file, extract it to the root of the C: drive as it will create a blat222 folder. The blat.exe file is located in the full subfolder along with a .lib and a .dll file. Copy these three files to the \winnt\system32 directory. You run the blat.exe file to "install" it. You need to use the IP address of your SMTP server when installing Blat which would be the IIS server. Installing Blat is simply a matter of running the program with the -install command-line switch and specifying the IP address of your IIS server and a sender address. Open up a DOS window and type in the command:
c:\winnt\system32\blat -install 172.16.1.20 administrator@yourdomain.com
This command sets registry values, etc. Specifying a legitimate (i.e. resolvable via DNS) domain name in the sender address is required if you want to send e-mail to external domains. (Note that you can rerun the Blat install command at any time if you want to change any of the values. Checking out the Blat documentation in the \blat222\docs subfolder may be valuable also.) By putting the blat.exe file in the \winnt\system32 you don't have to worry about permissions and the file is in the system path.

The following code will allow you to test a Blat installation to see if you can send mail from a script. Most of the statements are taken from various places in the Bestdam Logger script. They are the core of the Blat support in the script and of all of the command forms I tried these seemed to work the best. If you find a script you want to use that was only written to use Sendmail, you may be able to modify the script using this code to get it to run using Blat instead. (Keep in mind that the script will likely have different variable names for the $sendto, $subject, and path to the mail program so use those instead.)

Copy/paste the script into Notepad and change the $sendto e-mail address to yours. Save it in the directory you created for CGI scripts earlier using the name testmail.cgi. Be sure to enclose the name in quotes so Notepad doesn't append a ".txt" extension onto the name.

$blatpath = 'c:\\Winnt\\System32\\blat.exe';
$sendto = 'me@mydomain.com';
$subject = "Test Mail from Blat";

$blatprgm = "$blatpath - -t $sendto -s \"$subject\"";
open (MAIL, "|$blatprgm") || die 'Could not open mail program';
print MAIL "Test message\n";
close (MAIL); exit;

Open up a DOS window and cd\ into the scripts directory you created earlier. Check the syntax of the script with the command:
perl -c testmail.cgi
Then run the script with the command:
perl testmail.cgi
You can also check your CGI setup by trying to run the script from a browser. Open up IE on the IIS server and type the following URL into the address line (where the IP address is that of your IIS server):
http://172.16.1.20/cgi-bin/testmail.cgi
Whether run from the DOS prompt or browser you may see an error message like this:

The SMTP server doesn't like the name me@mydomain.com. Have you set the 'To: ' field correctly?

Despite this error, the e-mail address, surprisingly enough, is not what Blat doesn't like. If you look a couple lines lower you'll see:

The SMTP server response was -> 550 5.7.1 Unable to relay for me@mydomain.com

This is not a Blat problem or a script problem. It is a mail server configuration problem. The mail server is set to not relay e-mail messages, which is a common setting so your server doesn't get used by spammers. You have to change your e-mail server settings to allow relaying for the sending domain. With the IIS SMTP service, here's how you get to the routing restrictions:

• Right-click on the Default SMTP Site and select Properties
• Click on the Access tab
• Click on the Relay button
  
  
• On the Relaying Restrictions window click on the Add button
  
  
• Enter the IP address of the IIS server computer (the local machine)
  
  
• Click on the OK button
  

You could set the relaying a little looser to allow all computers on the subnet to relay for testing purposes.

However, I wouldn't recommend leaving it like this. Switch back to using a single IP address when you're done testing, especially if this is an Internet-connected server. Believe me, it doesn't take spammers long to find an open SMTP server.

Now try running the script again using the DOS window or browser and see if you receive the e-mail message. If you didn't, you can check to see what the SMTP service did with the message by using Windows Explorer to navigate to the \InetPub\Mailroot subdirectory. Look in the Bad, Drop, and Queue subdirectories for messages. They may be formatted for Outlook. However, right-click on them and select "Open with" and use Notepad to look at them. If you have any failure e-mails with the "Status:" of 5.0.0 it's typically a domain resolution issue. (Did you use a legitimate domain name in the sender address when you installed Blat?)

You may also want to use the "Open with" selection and use Notepad for .cgi and .pl scripts given that they're just text files. (Use the "always" checkbox to always open them with Notepad.)

Normally you don't want Blat's output puking all over your Web pages. There's a -q switch (quiet) that you can put at the end of the 4th line of the test script (and in other scripts) to prevent that. Once you're done with testing and everything is working, change the 4th script line so it looks like this:

$blatprgm = "$blatpath - -t $sendto -s \"$subject\" -q";

MS Java Chat Client 1j

Do you have MS Exchange 5.5 or BackOffice 4.5? Do you know that the MS Chat Server software that comes with Exchange 5.5 and BackOffice 4.5 doesn't need Exchange to run, just IIS?

If you want to try using the MS Chat Server software there's a neat Java-based chat client that Microsoft doesn't offer on their Website anymore. This Java chat client will let you embed a chat window on a Web page so your Web site visitors don't need a separate chat client software package. Just their browser.

I had a horrible time trying to find this chat client on the Web when I was setting up a chat page so I decided to make it available here for download. The mschat1j.exe file is also contained in the Microsoft Internet Client SDK if you can find a copy of that (good luck).

Setting up a chat room using the MS Chat Server software is pretty easy:

1. Set up an NT/2000 Server with IIS
2. Install the MS Chat Server software off of the Exchange 5.5 CD (or the Exchange CD of BackOffice 4.5)
3. Create a subdirectory (call it something like \chatroom) under the wwwroot directory on the chat server
4. Refer to the Chat Server software documentation on how to set up a chat room on the server (in this example we name the chat room MyChatRoom) and have the chat room reference the \chatroom directory created above
   
   Once the server software is all set up,
   
   
5. Download the mschat1j.exe chat client software and do the following:
   
   
   • The mschat1j.exe file is a self-extracting archive type of file. Simply extract the files (almost 70 of them) into a temporary directory and then copy or ftp all of these files into the \chatroom subdirectory on the server
     
     
   • Create an HTML file (a Web page that will display the chat window) giving it a name like mychat.htm and paste the following code somewhere between the <body> tags.
     
     <APPLET CODE="MSChat.class" ARCHIVE="mschat.jar" WIDTH="590" HEIGHT="450">
     <PARAM NAME="cabbase" VALUE="mschat.cab">
     <PARAM NAME="port" VALUE="6667">
     <PARAM NAME="room" VALUE="#MyChatRoom">
     <PARAM NAME="autodisconnect" VALUE="true">
     </APPLET>
     
     In the above code change the value of the room parameter to match the name of the chat room you set up on your server but be sure to leave the pound sign (#) in front of the room name.
     
     
   • Save this HTML file and copy or ftp it into \chatroom directory where the Java client files are located.
     
     Note that the Web page containing the above code MUST BE on the same IIS server that is running the MS Chat Server software and MUST BE in the same directory as the Java client files.

Note: Contained in the mschat1j.exe self-extracting archive file is a file with the name default.htm. View this file in your browser. It lists all of the different java applet parameters that you can use in the code block on the HTML page.

Once you've got everything set up. the URL to the Web page containing the embedded chat window would them be (using our example directory and file names):
http://www.mywebsite.com/chatroom/mychat.htm

Attention Network Administrators Monitor the temperature, humidity, and AC line power in your server room 24/7 with a Sensaphone. Cost of the Sensaphone 1104 unit and optional sensors is only around $400! It will dial pagers and deliver a synthesized voice message to cell phones. I do not have any financial interest is mentioning this. I simply want to pass along a good thing when I find it (and I was searching for something like this for weeks). Another gem is IP Sentry. Monitor your NT/2000 and UNIX/Linux servers (file, application, and Internet servers) 24/7 with e-mail and pager alerts. Monitors individual services on Windows servers and individual protocols (http, ftp, etc) on Internet servers. Only $99 and you can download a free trial version! I likewise have no financial interest in this product. If you're administrating NT/2000 networks you may want to check out Hyena. It basically takes User Manager, Server Manager, and a host of other administration utilities and rolls them all into on GUI interface. The Enterprise edition allows you to manage Exchange accounts (even manage Exchange accounts automatically when managing user accounts), all for $270. ($199 without the Exchange piece). You can download a free trial of this also. And you guessed it, no financial interest here either.

Top of page




Contents, diagrams, and images    Copyright © 2004-2023    Keith Parkansky    All rights reserved.
Certain graphics, symbols, and terms used on this site and in its documents are registered trademarks
of their respective owners and are contained herein for identification purposes only.
No endorsement of this site, its contents, or its documents by these owners is expressed or implied.

LIABILITY

IN NO EVENT WILL KEITH PARKANSKY BE LIABLE TO ANY PARTY (i) FOR ANY DIRECT, INDIRECT, SPECIAL, PUNITIVE OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, DAMAGES FOR LOSS OF BUSINESS PROFITS, BUSINESS INTERRUPTION, LOSS OF PROGRAMS OR INFORMATION, AND THE LIKE), OR ANY OTHER DAMAGES ARISING IN ANY WAY OUT OF THE AVAILABILITY, USE, RELIANCE ON, OR INABILITY TO USE THE INFORMATION, METHODS, HTML OR COMPUTER CODE, OR "KNOWLEDGE" PROVIDED ON OR THROUGH THIS WEBSITE OR ANY OF ITS' ASSOCIATED DOCUMENTS, DIAGRAMS, IMAGES, REPRODUCTIONS, COMPUTER EXECUTED CODE, OR ELECTRONICALLY STORED OR TRANSMITTED FILES OR GENERATED COMMUNICATIONS OR DATA EVEN IF KEITH PARKANSKY SHALL HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES, AND REGARDLESS OF THE FORM OF ACTION, WHETHER IN CONTRACT, TORT, OR OTHERWISE; OR (ii) FOR ANY CLAIM ATTRIBUTABLE TO ERRORS, OMISSIONS, OR OTHER INACCURACIES IN, OR DESTRUCTIVE PROPERTIES OF ANY INFORMATION, METHODS, HTML OR COMPUTER CODE, OR "KNOWLEDGE" PROVIDED ON OR THROUGH THIS WEBSITE OR ANY OF ITS' ASSOCIATED DOCUMENTS, DIAGRAMS, IMAGES, REPRODUCTIONS, COMPUTER EXECUTED CODE, OR ELECTRONICALLY STORED, TRANSMITTED, OR GENERATED FILES, COMMUNICATIONS, OR DATA. USE OF THIS SITE CONSTITUTES ACCEPTANCE OF ALL STATED TERMS AND CONDITIONS.