Microsoft FrontPage and IIS Tips 'n Tricks
by Brad Berson

Here is a one-page (OK, one long page) of lots of obscure information regarding Microsoft FrontPage, Personal Web Server and Internet Information Server.  I've included lots of mostly original code (except for tidbits hijacked from the MS documentation) and ask for nothing but a note of recognition if you use it.  Most of the tips are from lessons I've learned the hard way, and there's a more few hard knocks listed on the "Reasons to Hate Microsoft" page elsewhere on my web site.  Other items are documented but tough to find (like most things on Microsoft's web site and even more so if you choose to use Netscape).  Other things still are the stuff that FrontPage should do and doesn't, and Microsoft won't tell you.


Analyzing IIS4 and PWS Server Logs

I've written in ASP a quick 'n dirty log analyzer that detects whether it's running on NT or 95/98, and reads either the W3C extended format or the NCSA common format logs generated by the respective web servers (PWS or IIS4).   This is the only item on this page that isn't completely free for the asking, since the effort that has gone into this was not trivial.  I consider it to be Shareware, and ask only a measly US$10 if you find it suitable and choose to use it.   Sending me money puts you on an e-mail list when the code is updated, fixed or augmented as bugs or ideas are encountered.  It also earns you my eternal gratitude and assures me that my effort is appreciated.  The best part of this being ASP however, is that you can also modify it yourself to suit your personal requirements if you wish.

My ASP log decoder supports reading multiple log files, runs on Option Pack 4 PWS for 95/98 and NT IIS4 and later (requires Window Scripting Host to be installed for best operation - free DL from MS for 95, included in 98 and IIS4 for NT), and permits filtering (case sensitive and not).  Setting an obscure filter also has the effect of producing only the summary and statistical information without the table of page hits.  This kind of report fills all the holes left by reporting tools such as WebTrends.

The log analyzer reads only hits to HTM* and ASP files (true page reads) and generates a report containing the following:

  • Table of page hits containing the date/time, either the accessing host name (with link to respective TLD) or IP address (with link to ARIN/APNIC/etc lookups), the file accessed, the agent (browser), the referring page (or "-" if direct hit or "+" if followed from another page on own site), and the query data from referring sites.
  • Count of text matches and number of files processed, if a filter string is supplied.
  • Summary of overall page reads, and how many of those were direct, or referred from outside, and how many were followed by clicking from other pages on your site.
  • Tally of specific hits to a user-configurable list of special pages that the user may be interesting in keeping track of individually (such as default.htm, etc.).
  • List of "inline" hits, which sometimes reveals when other web sites have done rude things like linking to your graphics images or scripts from within their own web pages.
  • Tally of the referring sites sending users to your web site (searchs engine and general sites), and how many referrals there were from each site.  This list includes HTML links back to the referring sites/pages.
  • Table of search engines referring people to your site, the search term used, and the page to which that the search engine referred.
  • Summary of error codes (only "400" and above), which can help reveal broken links on your site or indicate when visitors are looking for elements on your site that have been moved or deleted or possibly never existed.  Also alerts you to hacking attempts.

Click HERE to open a browser page showing a brief example report.

Some of the coding tricks include:

' Detect what platform script is running on, and find path to Windows dir
' Requires Windows Scripting Host - free DL from MS or installs with Win98, NT IIS4
Set WshShell = Server.CreateObject("Wscript.Shell")
Set WshSysEnv = WshShell.Environment("PROCESS")
OperatingSystem = WshSysEnv("OS")
IF INSTR(OperatingSystem,"NT") > 1 THEN
  WinDir = WshSysEnv("SYSTEMROOT")
  WindowsNT = True
ELSE
  WinDir = WshSysEnv("WINDIR")
  WindowsNT = False
END IF
Set WshShell = Nothing
' Function to translate %nn hexadecimal format characters from URI...
' Replaces with either translated data or a space depending on TranslateMode.
' This handily makes up for lack of JavaScript -like Unescape function.
Function Unescape(EscapedString,TranslateMode)
  DO WHILE INSTR(EscapedString,"%")
    Perc = INSTR(EscapedString,"%") 
    IF TranslateMode THEN
      ' Replace escape string with actual data...
      HexData = MID(EscapedString,Perc+1,2)
      Character = CHR("&H" & HexData)
    ELSE
      ' Replace with a space instead...
      Character = " "
    END IF
    EscapedString = LEFT(EscapedString,Perc-1) & Character & MID(EscapedString,Perc+3)
  LOOP
  ' Make sure we output html-friendly data...
  Unescape = Server.HTMLEncode(EscapedString)
End Function
' Function to get search terms from the URI on a search engine referral...
' relies on defined ASP Unescape() function!~
Function QueryData(QueryString, skeys)
  ' skeys is a space-separated list of keywords to consider as search param candidates.
  ' example: "searchtext searchwd keywords keyword general search query text ask key qry mt qt qr sc p q r s"
  ' skey becomes a 0-based array those keywords.
  ' QueryData is everything past the "?" on a URI
  skey = SPLIT(skeys)
  ' Need to prepend for reliable str search since all params except first start with '&'...
  QueryString = "&" & QueryString
  FOR i = 0 to UBOUND(skey)
    Test = INSTR(LCASE(QueryString),"&" & skey(i) & "=")
    IF Test > 0 THEN
      StartPos = Test+LEN(skey(i))+2
      QueryString = MID(QueryString,StartPos)
      ' Lop off the rest of params if there...
      EndPos = INSTR(2,QueryString,"&")
      IF EndPos>0 THEN
        QueryString=LEFT(QueryString,EndPos-1)
      END IF
      EXIT FOR
    END IF
  NEXT
  ' Convert %xx codes and trim...
  QueryString = Unescape(QueryString,1)
  QueryString = Replace(QueryString,"+"," ")
  QueryData = Trim(QueryString)
End Function

If this script interests you, just send e-mail to brad.berson at ("@") rectaltronics.com, or fill out and submit the second form on the page linked here: [COMMENTS], and don't forget to include your e-mail address and name.

Go back to top.

MIDI background sound with Netscape

This is a battle fought on two fronts. You need HTML code on your page that handles both Internet Explorer and Netscape; and for Netscape to play MIDI without silly plug-ins, the web server needs to encode the MIDI files with the proper MIME type on the way out.

To put the right code into Frontpage: insert a Plug-In, and define the Data Source as the MIDI file, such as canyon.mid. Then in the Message for Browsers Without Plug-In Support, insert <bgsound src="canyon.mid" loop=infinite>. Check the Hide Plug-In box, put in 0 for Height and 2 for Width, and you're done. Alternatively, you can insert HTML Markup and provide the code: <embed src="canyon.mid" hidden="true" width="2" height="0" autostart="true" loop="true"><noembed><bgsound src="canyon.mid" loop=infinite></noembed>

The same tactics work for WAV files. You can put parameters such as autostart=true in through the extended properties option on the Plug-In properties page.

The web server needs to encode the MIDI file as MIME-type "audio/midi" for Netscape. Depending on the web server this could require changes to its mime.typ file or a srm.conf file, or in the case of Internet Information Server 4, this can be done using the IIS Management Console GUI. In the web site properties, select the HTTP Headers page, click on File Types..., click New Type..., and enter mid for the Associated Extension and audio/midi for the Content Type (MIME). Do the same for midi as well. The site (not the whole machine) will then have to be stopped and re-started for this new setting to take effect.

Go back to top.

Perl scripts on Microsoft Web Servers

First, a note about PWS vs PWS vs FP PWS... PWS is the Microsoft Personal Web Server, which comes with FrontPage97 and installs on Windows95. It won't install on any flavor of NT. It sits in your system tray when loaded. FP PWS is the MS FrontPage Personal Web Server, which doesn't know what a system tray is. It's based on the old NCSA HTTPD daemon and so uses more traditional configuration and control files as well. This is what is installed if you put FrontPage97 on Windows NT 3.x or later. Lastly there's the MS Peer Web Services, which are installed from FrontPage98 whether it's on Windows 95 or NT4. It's also available in Microsoft Option Pack 4.

Go to ActiveState Tool Corp at http://www.activestate.com, where you can download the latest version of Perl5 interpreter and other tools. These are the same folks who supplied the Perl that is bundled with Windows NT Server and the Resource Kit. From there you can also find links to help you get Perl working on your system. It's pretty much run 'n go, but I'll save you a little trouble with the following hints...

FrontPage Personal Web Server...

I haven't been able to get the FP PWS to cooperate in a secure manner with Perl on NT yet. I'm sure it's possible, so if anyone knows please tell me. All I know for sure is, NEVER put the PERL.EXE program into your .\cgi-bin directory. Documented major damage potential if you do. If you're absolutely positive that nobody but you will ever access the server, this is the only situation where it has any level of safety. But remember that unless you have your own firewall, the moment you connect to the Internet without disabling the web server, you are vulnerable.

Personal Web Server...

The installation program does not insert a required registry key.

Peer Web Services...

Coming soon!

Internet Information Server 4...

The installation program usually does not insert a required registry key...
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W3SVC\Parameters\Script Map]
".pl"="C:\PERL\BIN\PERL.EXE %s"
There's also a PerlIS component that can be installed. It has a similar memory footprint and benchmark performance but runs within IIS's memory space, and so may provide performance benefits in multihosted configurations. OTOH, since it runs in IIS's memory space it could potentially lessen web server stability.

FYI, I've found performance of VBScript to be roughly the same as Perl on a horribly over- committed IIS4 test machine.

Go back to top.

HTML editing versus the GUI approach

Adding HTML Markup on your page looks ugly and deceiving during editing. As your exposure to web site production grows, you'll find more and more situations where you find hints and suggestions and snippets to use. Wouldn't it be nicer not to put them into ugly Markup WebBots?

An example of this can be found above in the "MIDI Background Sound With Netscape" section. Many non-standard things can be inserted as Plug-Ins. The field for Message for Browsers Without Plug-In Support can be more than plain text, too. HTML codes work just dandy there. Instead of using Markup for counters and banners, you can insert the corresponding images with the GUI and specify the link data via the GUI as well.

Using the FrontPage GUI to add file elements to your web pages has the benefit of being more WYSIWYG in the FrontPage Editor, and not leaving "orphaned" (unlinked) files in the web site view in FrontPage Explorer. The only good reason for not doing this is that during editing, this will register false counter hits and use up bandwidth while loading external images. Leaving this type of HTML code in Markup avoids both issues altogether.

Go back to top.

Differences Between Netscape and Microsoft Internet Explorer

Microsoft FrontPage thoughtfully permits you to write HTML pages that take advantage of many of the features built into Microsoft's Internet Explorer.  It should come as no surprise then, that the same people whose web site is nearly unusable if you use Netscape have written software that doesn't tell you when you're about to create a web site of your own that's equally crippled for anyone not lining Bill Gates' pockets.

Netscape 4.x has remedied some of the problems but here are a few things to keep in mind.  Don't use margin settings.  Add wrap="virtual" to TEXTAREA tags for scrolling text boxes.  Stay away from styles.  Don't mix indents and centering on the same paragraph.  Watch out for table/cell backgrounds.   Use backgrounds instead of watermarks (or set both to keep 'em all covered).   Make sure that you use the proper EMBEDs (and NOEMBED) for sounds on both platforms.

Another thing to keep in mind is platform compatibility with regards to font (or "face" in HTML- speak) specification.  You would thing that FP98 permits specifying a secondary, alternate font to use through its styles but that actually worsens compatibility by using style sheets.

Go back to top.

Differences Between Web Services on NT and Win9x

You may have thought you had it all figured out when you knew the mere difference between the Frontpage Personal Web Server and the Peer Web Services that ship with FrontPage97, and the Option Pack 4 PWS for Win9x and the Option Pack 4 Internet Information Server.  But then you start noticing that the things that work OK on Win9x or even on NT Workstation don't seem to work on NT Server.  Particularly when you're trying write files or access system functions.

It all boils down to rights.  Win9x doesn't have much in the way of security so almost anything goes.  NT Workstation and NT Server have plenty of security, but install with two completely opposite default rights models.  Try this snippet of ASP code, which determines your web root path and attempts to find and display the total size of your web site's files including subdirectories.  You can find similar code in many other ASP web sites.

Set MyFileSize = Server.CreateObject ("Scripting.FileSystemObject")
MyPath = Request.ServerVariables("APPL_PHYSICAL_PATH")
MyPath = LEFT(MyPath,LEN(MyPath)-1)
Response.Write MyPath & "<br>"
Set MyFolder = MyFileSize.GetFolder(MyPath)
Response.Write "Web folder total size is " & FORMATNUMBER(INT(MyFolder.Size/1000),0) & " Kb."

Running this on Windows9x, it works fine.  Try it on NT and you'll get an error.  That's because the IUSR_Machine account created by IIS4 does not have sufficient priveleges to go digging through your subdirectories.  What none of the other ASP web sites tell you is that if your ASP page forces user authentication, it works fine.  Try this code before any of the HTML on your page when the page is running on NT:

If Request.ServerVariables("LOGON_USER") = "" Then
  Response.Status = "401 access denied"
  Response.End
End If

This brings up a logon dialogue in the browser and requires you to enter your Windows NT account name and password.  The problem of course is that this works fine for you, but you can't show it to everyone!

Go back to top.

FrontPage Extension Follies on Internet Information Server

SearchBots...

Does your search 'bot work fine on your personal web server but return unpredictable results when published to an IIS web server? Does it return results from other people's pages, or from IIS's help pages, or nothing at all? Microsoft Index Server is at the heart of your woes.

The FrontPage SearchBot when running against a personal or peer web server is coded by FrontPage to use a search system based on the older and relatively WAIS (Wide Area Information Server) system. This relies on a set of index files maintained individually by each FrontPage web site. The FrontPage SearchBot when running against an IIS server without Index Server installed behaves in the same manner.

The FrontPage SearchBot when running against (or publishing to) a multihosting IIS server with Index Server installed, by default codes (or translates) SearchBots to use Index Server. Unfortunately, few ISP's when setting up a new virtual web site know to either (a) go the extra step of adding the required Index Server catalog for your site, or (b) adding NoIndexServer=1 to the web server's FRONTPG.INI file.

Index Server does not automatically create new catalogs when you create new virtual web sites. Each site must have its own catalog. A server administrator adds the catalog by using the Index Server management console, right-clicking the Index Server On Local Machine folder, selecting New | Catalog, giving the catalog a name matching the virtual site name, supplying the path to the desired virtual web root, and assigning a Virtual Server from the Web page (second tab).

Further confusion can arise if the multihosting web server in question does not have one particular IP address assigned to the default web site. Typically this setting is "all unassigned" IP addresses. This IP address should be specifically assigned.

FRONTPG.INI can over-ride the FrontPage extentions back to WAIS. Add the NoIndexServer=1 line under the [FrontPage 3.0] heading to affect all virtual web sites on the physical server, or add the line under the appropriate [Port...] heading to affect virtual sites individually. Rebooting the server is not necessary. The affected web pages with SearchBots will be re-coded the next time you do a Tools | Recalculate from FrontPage.  More information on this issue and how to fix it can be found below (click here).

Default Page Name...

Take my advice. Stick with Default.htm (and Default.asp) if you're going to publish to an IIS web server. Purists and old-timers may feel tempted to change their Personal Web Servers and Peer Web Services and so on to "index.htm", and that's just fine. Then when you publish to site to IIS it changes the name to Default.htm at the server anyway. This causes predictable weirdness when it comes time to maintain the site via FTP or a shell (TELNET) account. It also causes trouble with the Table of Contents WebBot. And if you copy the index.htm to your site manually and subsequently use FrontPage to open the site directly, your navigation view of the web site will be askew.

If you try to get slick and change the IIS web server virtual site settings to recognise only index.htm, it will not change FrontPage's behavior and you'll end up with your web site audience staring at an error page as the server looks for index.htm and you've published default.htm.

Go back to top.

Working on FrontPage Webs With Other Programs

I didn't notice this conspicuously documented anywhere, but your life can be made simpler with the use of the [F5] (Refresh) key in the FrontPage Explorer.

When adding or changing files in the FrontPage web directory using programs other than FrontPage, the updated information or new files will not appear in FrontPage Explorer or FrontPage Editor until you either "import" those files or... press [F5]! The former is the recommended method (actually it's recommended not to touch the directory's files with any programs other than FrontPage) but it is awkward and unnecessary.  Don't delete files from your site's content directory using anything but FrontPage, or you'll have orphaned files in control subdirectories.

Be careful of programs like Adobe Photoshop when editing with FrontPage. Photoshop is a terrible memory hog, and FrontPage sometimes mysteriously loses page or item elements when it runs short on memory. It loses things you won't notice right away, like the extended properties on a hyperlink where you've defined "onmouseover" events, etc.  FrontPage98 has improved things a bit but be careful.

Go back to top.

Limitations of FrontPage

No "mouseover"'s on FrontPage image maps. So unless you program it by hand or with other software and insert it as Markup, you can't do image rollovers, status bar updates and other Javascript stunts on image maps. The alternative is to break the image up into pieces with a GIF or JPG editing program and define the necessary links and extended properties for mouseover's on each piece of the image.

FrontPage tries to be smart about some differences between HTML interpretations in IE and Netscape, but you have to be smart too. Watch out for image alignment (right, left, middle, etc.), mixing indents and centering, and use of top and left margins.

Go back to top.

Firewalls and SOCKS

SOCKS is a popular method for permitting non-HTTP traffic to get across a firewall, such as FTP, Telnet, etc.  Software such as sockscap get between your software and your TCP/IP protocol and help get your packets through SOCKS to your destination and back.  SOCKS can also handle HTTP traffic but it incurs subtantial overhead with no real advantages, so sometimes a SOCKS server is configured to block HTTP.

If you get a message like "no server on port 80" when you try to open your web site through a firewall and SOCKS proxy server with FrontPage, it's most likely because HTTP is blocked in SOCKS and you need to tell FrontPage about your HTTP proxy server (Tools/ Options/ Proxies) instead of letting SOCKS handle it.

Go back to top.

ASP (VBScript) Development

Having been bitten by the problem of variable scope too many times, I can't possibly stress enough the value of putting your main code section into a subroutine. This keeps you from mixing up truly global variables with those that are defined for the main code section, and avoids conflicts with variables defined in other functions and subroutines. Usual victims are loop control variables such as "i", that tend to be defined in many places.

Use OPTION EXPLICIT at the top of your code and explicity define ("Dim") every variable you wish to use. Use as few global variables as possible.

If you haven't upgraded to FrontPage98 yet, here is one great reason to do so: It comes with Peer Web Services and support for ASP. Debugging your ASP stuff locally beats the heck out of the edit / publish / test / curse / edit cycle.

To ensure the widest audience, let the server run the VBScript for you! Not everyone has a VBScript-compatible browser. Of course, this requires that your web server be ASP -capable.

Go back to top.

ASP (VBScript) Debugging

When your ASP program encounters an error, the VBScript engine thoughtfully tells you what the error was, along with the usual mysterious error code and a line number.  But Frontpage doesn't give you line numbers and in fact, nor does any other program that ships with Windows.  Unless your pages are very brief and/or all your code is at the top of your pages, this makes it tedious at best, to figure out what the offending line of code was.

Fear not!  There IS help, and it's called ViewCode.ASP.   Microsoft had this ASP program carefully hidden away in the dark recesses of their web site that is designed to print to HTML a nicely formatted, color-coded copy of an ASP page.  I have found this gem and taken the liberty of stripping away some style-sheet stuff for the sake of some dinosaurs, and adding some optional line-numbering code since the original also did not provide any facility for line numbers.  The program also gives each line number a NAME tag so that you can link directly to an offending line of code.  The NAME tag feature is not of great use right now but will be with IIS 5.0, whose err object finally supports a line number property (so you can make your own error handler routine that prints a hyperlink to ViewCode).

Click here to get a copy of viewcode.asp in text form.
Depending on your browser/OS, use shift- or command-click, or use File/Save As... to save the file, and then you will have to rename it from ViewCode.txt to ViewCode.asp on your web server to use it.
Click here to see viewcode.asp in action!
Code for the above link: viewcode.asp?source=viewcode.asp&numbered=yes#58
This gives you numbered source code and takes you directly to line 58.   Leave off everything past the "&" for operation without line numbers.
Click here to see another way viewcode.asp works
Code for the above link: viewcode.asp?source=viewcode.asp&numbered=yes&line=58
This gives you numbered source code and puts a link at the top of the source code to take you to line 58.   This uses the line parameter instead of a hashmark, making it suitable for use from form GET operations such as the following:
<form method="GET" target="_blank" action="viewcode.asp"><input type="hidden" name="numbered" value="yes"><p>Filename: <input type="text" name="source" size="20"> Line Number: <input type="text" name="line" size="5"><input type="submit" value="Display"><input type="reset" value="Reset"></p></form>

Go back to top.

ASP and Beyond with Windows Scripting Host

If you're feeling stymied by the low-level limitations of VBScript as it exists through IIS4 Active Server Pages, you may be able to take advantage of WSH - Windows Scripting Host - to fill in the gaps.  Nobody really tells you this, of course.  But there are plenty of things you can do.  For more information and documentation, open the URL http://msdn.microsoft.com/scripting/.   Meanwhile, here's a few examples of the mischief you get into:

Set obj = Server.CreateObject("Wscript.Shell")
Set nobj = Server.CreateObject("WScript.Network")

Response.Write "Environment Strings...<BR>"
For Each strTemp In obj.Environment("PROCESS")
  Response.Write strTemp & "<BR>"
Next

strTemp = obj.ExpandEnvironmentStrings("%SYSTEMROOT%")
Response.Write "SystemRoot String: " & strTemp & "<BR>"

strTemp = nobj.UserDomain
Response.Write "MSnet Domain name: " & strTemp & "<BR>"
strTemp = nobj.UserName
Response.Write "MSnet Current User Name: " & strTemp & "<BR>"
strTemp = nobj.ComputerName
Response.Write "NT Computer Name: " & strTemp & "<BR>"

strTemp = obj.SpecialFolders("AllUsersPrograms")
Response.Write "All Users Programs Folder: " & strTemp & "<BR>"
strTemp = obj.SpecialFolders("Favorites")
Response.Write "Favorites Folder: " & strTemp & "<BR>"

strTemp = obj.RegRead("HKCU\Environment\TEMP")
Response.Write "Temporary Directory: " & strTemp & "<BR>"
strTemp = obj.RegRead("HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\CurrentVersion")
Response.Write "NT Current Version: " & strTemp & "<BR>"
strTemp = obj.RegRead("HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\CSDVersion")
Response.Write "NT CSD Version: " & strTemp & "<BR>"
strTemp = obj.RegRead("HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\CurrentBuildNumber")
Response.Write "Current NT Build: " & strTemp & "<BR>"

What's especially neat about WSH is that given sufficient process permissions, you can access just about any registered COM object on the server. 

Go back to top.

Checking FrontPage Counters

When you use the Frontpage counters on many of your pages, there's no decent way for you as an the proprietor of your web site to have a quick glance at the counters on each page without visiting them all.  The Frontpage Extensions keep those counts using files in the _private subdirectory of your web root, and they bear the name of the web page they're on with ".cnt" appended.  This little script reads those files and displays the counts inside them.  This script does things the hard way - there are installable MSWC components (if they're installed) that could read the data without using a text stream - but you still have to enumerate and loop through the available counters.

' build path to .cnt files...
WebPath = Request.ServerVariables("APPL_PHYSICAL_PATH")
FileSpec = WebPath & "_private"
' stolen code to get list of files in folder...
DIM fs, f, f1, fc
SET fs = CreateObject("Scripting.FileSystemObject")
SET f = fs.GetFolder(FileSpec)
SET fc = f.Files
' loop through each file in folder...
FOR EACH f1 IN fc
  ' is it a cnt file...?
  IF RIGHT(f1.name,4) = ".cnt" THEN
    SET mfo = Server.CreateObject("Scripting.FileSystemObject")
    SET tf = mfo.OpenTextFile(FileSpec & "\" & f1.name)
    ' file has format: FPCountData 00000000000
    ' get the numbers out of it...
    WHILE NOT tf.AtEndOfStream
      fname = LEFT(f1.name,LEN(f1.name)-4)
      CntData = tf.ReadLine
      Count = MID(CntData,INSTR(CntData," ")+1)
      Response.Write(fname & ": " & Count & "<BR>")
    WEND
    tf.Close
    SET mfo = Nothing
    SET tf = Nothing
  END IF
NEXT

Go back to top.

Modifying FrontPage Counters

Microsoft FrontPage comes a counter component that works on pages hosted on Internet Information Server.  Unfortunately you're given only five choices that range from obtrusive to garish.  You also have a choice to use "CUSTOM.GIF" but good luck looking for help on just what CUSTOM.GIF is supposed to be.

The cheap way out would be to point you to http://www.digitmania.holowww.com, but that only gives you lots of choices of digit styles and not much technical information.  Fortunately, in spite of the lack of documentation it's actually very easy to create custom GIFs for counters.

The CUSTOM.GIF file needs to be the digits 0 through 9 - 0123456789 - spaced evenly across one line.   You can create this file in Image Composer or Photo Editor, or Photoshop or whatever for you sophists.  If you wanted digits that were 9 pixes wide and 12 high, your GIF's dimensions would be 90x12 pixels, and the characters would have to be placed in their correct positions in the GIF.

A word of warning - some readily available counter digit GIF's are made "1234567890" or have extra characters at the end like "!" or "am" or "pm".  You'll have to edit these or they'll be worse than useless!  Any image set whose digits were spaced proportionally will also be useless.  Sometimes this editing can be as tough as simply starting from scratch with your own work, so keep that in mind.

One thing that many counter GIF's don't use is transparency.   This can make the counter seem much more integrated with the page but be careful of weird contrasts and jaggies with mis-matched background and GIF colors.

An alternative to the potentially garish GIF's, but only from ASP pages, is to employ the Page Counter component.  This may not be installed in IIS by default and I try to make most of the information on this page as portable as possible so the discussion should remain brief:

' Initialize the counter object...
Set MyPageCounter = Server.CreateObject("MSWC.PageCounter") 
' Register a hit through the object...
MyPageCounter.PageHit
' Now tell them how many hits with ordinary text...
Response.Write "[" & MyPageCount.Hits & "hits]"

Go back to top.

Index Server and FrontPage Search Forms

If your Internet Information Server web server is hosting multiple virtual web sites and has Index Server installed, and your web site is not the server's "default" web, use of the Frontpage searchbot will likely return unpredictable results.  This is because by default, Frontpage expects to use Index Server to retrieve the information and in turn, Index Server needs to be explicitly configured for each virtual web site running on the web server.  Few webmasters know to bother.

The fix seems very simple - insert a line "NoIndexServer=1" in the web server's FRONTPG.INI file (located in the web server's Windows NT directory).  This entry can be under the [FrontPage 3.0] section to apply to all virtual webs on the server, or under the corresponding [Port /LM/W3SVC/n:] section to affect only your virtual web.  There are two problems.  You may need to figure out what n: is for your web site if you don't want this to affect all the webs, and you need to access the FRONTPG.INI file on the web server (not easy if your ISP is not cooperative).  But all is not lost!

If all you need is to figure out your own section in FRONTPG.INI, this little snippet of ASP script will tell you:
Response.Write(Request.ServerVariables("INSTANCE_META_PATH"))

If you have no way of getting to FRONTPG.INI, you might use the following script to get the job done.  For this to work, your Frontpage web must have write privileges in the Windows NT directory of the web server (not likely but you never know), and this script must be transcribed perfectly or disaster could easily follow.  Shame on me for not using OPTION EXPLICIT...

Response.Write("Repair FRONTPG.INI file...<br>")
' Get Windows NT base drive and directory...
Set fso = CreateObject("Scripting.FileSystemObject")
WinDir = fso.GetSpecialFolder(0)
' Build full path to INI file...
IniFileName = WinDir & "\FRONTPG.INI"
Response.Write("Targeting " & IniFileName & "...<br>")
' Get that pesky port name and number...
MetaPath = Request.ServerVariables("INSTANCE_META_PATH")
' Build that into a full section name string...
SectionName = "[Port " & MetaPath & ":]"
' Tell us whats happennig...
Response.Write("Repairing Section " & SectionName & "...<br>")
' Hope that INI file is less than 1000 lines long...
dim arrIniFileArray(1000)
IniFileRecords = 0
FoundSectionAt = 0
' We will set Barf to 1 if anything goes wrong...
Barf = 0
' Open INI file...
Response.Write("Reading File...<br>")
Set mfo = Server.CreateObject("Scripting.FileSystemObject")
Set IniFile = mfo.OpenTextFile(IniFileName)
' Read it into array...
WHILE NOT IniFile.AtEndOfStream
  LineData = IniFile.ReadLine
  IniFileRecords = IniFileRecords + 1
  arrIniFileArray(IniFileRecords) = LineData
  Response.Write("(" & IniFileRecords & ") " & LineData & "<br>")
  ' Note line number of beginning of our section...
  IF LineData = SectionName THEN
    FoundSectionAt = IniFileRecords
  END IF
WEND
IniFile.Close
' Make sure we dont lose any lines...
IF IniFileRecords > Ubound(arrIniFileArray) THEN
  Response.Write("<br>Error: INI file too large!<br>")
  Barf = 1
ELSE
  IF FoundSectionAt = 0 THEN
    ' Abort if we cant find our section...
    Response.Write("<br>Error: could not find section!<br>")
    Barf = 1
  ELSE
    Response.Write("<br>Total read " & IniFileRecords & " records.<br>")
    Response.Write("Section found at line " & FoundSectionAt & ".<br>")
  END IF
END IF
Response.Write("Finding Record...<br>")
IF Barf = 0 THEN
  FoundRecordAt = 0
  ' Start looking for record just past section header...
  FOR i = FoundSectionAt + 1 TO IniFileRecords
    IF LEFT(UCASE(arrIniFileArray(i)),13) = "NOINDEXSERVER" THEN
      ' Halelujah we found the line with NoIndexServer!
      FoundRecordAt = i
      Response.Write("Found record at line " & FoundRecordAt & ".<br>")
      Response.Write("<b>" & arrIniFileArray(i) & "</b><br>")
      EXIT FOR
    ELSE
      IF LEFT(arrIniFileArray(i),1) = "[" THEN
        ' get out if we fall into next section...
        EXIT FOR
      END IF
    END IF
  NEXT
  IF FoundRecordAt = 0 THEN
    ' Sonofagun we reached end-of-file without finding record...
    Response.Write("No <i>NoIndexServer</i> record exists.<br>")
  END IF
ELSE
  Response.Write("Skipping!<br>")
END IF
Response.Write("Updating Record...<br>")
IF Barf = 0 THEN
  IF FoundRecordAt = 0 THEN
    ' If record wasnt there we must insert.
    ' Begin by moving everything past our section up 1 in array...
    FOR i = IniFileRecords + 1 TO FoundSectionAt + 1 STEP -1
      arrIniFileArray(i) = arrIniFileArray(i-1)
    NEXT
    ' Now put our entry into place...
    arrIniFileArray(FoundSectionAt + 1) = "NoIndexServer=1"
    Response.Write("Record <i>NoIndexServer=1</i> has been added.<br><br>")
    ' Dont forget to update our line count...
    IniFileRecords = IniFileRecords + 1
  ELSE
    ' Record was there - change it only if necessary.
    IF (RIGHT(TRIM(arrIniFileArray(FoundRecordAt)),0)="0") OR (RIGHT(UCASE(TRIM(arrIniFileArray(FoundRecordAt))),5)="FALSE") THEN
      arrIniFileArray(FoundRecordAt) = "NoIndexServer=1"
      Response.Write("Record changed to <i>NoIndexServer=1</i>.<br>")
    ELSE
      ' We dont want to rewrite if its OK already...
      Barf = 1
      Response.Write("Record is already correct!<br>")
    END IF 
  END IF
ELSE
  Response.Write("Skipping!<br>")
END IF
Response.Write("Writing File...<br>")
IF Barf = 0 THEN
  ' Open new INI file for overwrite...
  Set nfo = Server.CreateObject("Scripting.FileSystemObject")
  Set NewIniFile = nfo.CreateTextFile(IniFileName,True)
  ' Write out all the records...
  FOR i = 1 TO IniFileRecords
    NewIniFile.WriteLine(arrIniFileArray(i))
  NEXT
  NewIniFile.Close
  ' Re-open file for read...
  Set mfo = Server.CreateObject("Scripting.FileSystemObject")
  Set IniFile = mfo.OpenTextFile(IniFileName)
  ' And display the new file for warm fuzzy purposes...
  WHILE NOT IniFile.AtEndOfStream
    Response.Write(IniFile.ReadLine & "<BR>")
  WEND
  IniFile.Close
ELSE
  Response.Write("Skipping!")
END IF
Response.Write("Done!<br><br>")

Go back to top.

META Tags and ROBOTS.TXT

Search engine web sites have software called "robots" or "spiders" that go to web sites and work their way through all of your pages, link by link, indexing the information in them.  If you make their job easier, they will do a better job of indexing your site's content.  If there is content you want to keep them out of, most robots will politely read a special file called ROBOTS.TXT that tells them where to look and where not to look.  In the pages you want them to index, you can add special code to tell the robots what you're all about.

If you want successful links from search engines, it's essential to at least add a few "META tags".  These are additional variables that are added in the HEAD section of an HTML document and give additional information about your page.  To see the usual ones from FrontPage, click File, Page Properties, then click on the [Custom] tab.  You'll see at least a "GENERATOR" keyword and possibly "FORMATTER" as well.  In HTML they look like <META NAME="AUTHOR" CONTENT="BRAD BERSON">

You should add "AUTHOR", "DESCRIPTION" and "KEYWORDS" to all of your major web pages.  Author should of course be your name.  Description can duplicate the HTML TITLE of your web page, but should include a more thorough description of content.  Keywords should be a list of words or phrases separated by commas that can identify the content and/or purpose of your web page.  For example, this web page's keywords are FrontPage, IIS, IIS4, Internet Information Server, ASP, Active Server Pages, VBScript, Javascript, HTML, Tips, Tricks, Hints, PWS, Personal Web Server, Peer Web Services, Index Server, WSH, Windows Scripting Host, Brad Berson.

The file ROBOTS.TXT should be placed in the root directory of your web site directory where your default web document (default.htm or index.htm) is.   Edit it to look like something this:

# robots.txt for http://www.yoursite.com/
User-agent: *
Disallow: /cgi-bin/
Disallow: /_private/

Disallow: /_vti_bin/

Under the "Disallow" entries add whatever other subdirectories you want to keep the robots from delving into.  Beware - most robots are polite enough to obey the restrictions but NOT all.

Robots also obey some META tags.  A tag named "ROBOTS" can have values like "noindex,nofollow", "index,follow", or combinations thereof to specify whether or not to index the page or referenced pages.  A tag named "REVISIT-AFTER" can have a value like "10 days" to specify how often to come back and re-index your site.

Some other handy META tags can do things like keeping your web page from being cached by browsers.  This can be very useful for pages that change often or even with every visit, to make sure that your visitors always see current content.  There are two ways to do this:

<meta http-equiv="Pragma" content="no-cache">
<meta http-equiv="Expires" content="-1">

Go back to top.

Security and the _private/ Directory

Take the _private directory seriously, especially if you use the FrontPage Search Bot.  Just because something isn't linked or you think people don't know the URL to a private file, doesn't mean that the Search Bot can't find it.

If you want something to be private, keep it in the _private subdirectory or any other subdirectory away from the web root whose name begins with an underscrore ("_").  The Search Bot and the Table of Contents Bot both ignore anything in a directory beginning with an underscore.

Go back to top.

FrontPage Subweb Configuration

If you use FrontPage Explorer to create a new FrontPage web under the currently opened web, you may find that users trying to browse the subweb are asked for server credentials and cannot access the subweb.  Then, thinking you're smart, you click Tools, Permissions, and try to set "Everyone has browse access".  But FrontPage complains about the web server account passwords and it doesn't work.  Don't worry.  Set the subweb not to use the same permissions as the root web, click Apply, select the Groups tab and click Add, then select "Network" or "Domain Users" from the list.

Go back to top.

FrontPage Borders

FrontPage shared borders make a handy place to universally apply things like copyright notices, time stamps, and even page counters.  But if your web site does not have an up-to-date framed navigation system, you may be losing a lot of potential browsing traffic to people who land on some page on your site from a search engine, and have no idea how to get to the rest of your web pages.

Put a link to your default web page in a FrontPage shared border!  I've even gotten fancier and included some Javascript that detects whether you came from a search engine or a referring web site, and if so, displays some extra text prompting the user to come in and have a look around.

The one caveat to FrontPage shared borders is that everything is displayed within a one-cell table.  As a result, any JavaScript you use in a shared border may not be seen by visitors using Netscape 3.x, which has a bug that makes rendering Javascript output in a table cell very unpredictable.

Go back to top.

Catering to MSIE5

Microsoft Internet Explorer 5.0 introduces a few novel features, one of which can be useful for webmaster's narcissistic thrills.   When an IE5 user adds a site to their list of "Favorites", IE5 checks the root of the web site for a file called favicon.ico.  If that file exists, it is used for an icon to represent that site or link in the Favorites list.  This is a standard 32x32 Windows icon file.

Webmasters should come up with a clever icon for their sites and put them on line right away. I've already noticed several accesses on that filename per day on this site, and IE5 is barely out of beta!

Webmasters might also be interested in tracking hits to favicon.ico in their log files, to get a different measure of interest in their site and various pages.  A little trickery is required to make good use of this however.  The referring page (HTTP_REFERER) is not noted in the web log entries for hits to favico.ico, so you have to backtrack in the log to see what page actually sparked the interest.  My ASP Log Decoder program does this just fine.

You can use the Image Editor tool in the Windows Resource Kits to create icon files, or download shareware.  The Windows utilities will only create 4-bit color maps (16 color).  We all know Windows can do better than that!  E-mail me with your favorite program for creating 256-color and better icons and I'll post the link here.

You can find more information about favicon.ico at http://www.favicon.de.

Go back to top.

Binary Data Output

Situations where you would want binary output include using ASP to directly create and write graphics images or other native non-text file formats.  For instance, instead of <img src=filename.jpg> to display a file on your page, you could extract that image from a database (<img src=GetImgFromDB.ASP?id=<%=RecNum%>).  The GetImgFromDB.ASP file would do the work of looking up the record RecNum, extracting the image from a binary database field into a special variable, and using Response.BinaryWrite() to output the data.

If you are extracting the image from a database, the DLL's that interface to the database create a special kind of array called a SafeArray, which works nicely with Response.BinaryWrite().  But if you're creating the image with ASPcode or are extracting binary data from another source (such as a file), you end up with variables that produce unavoidable extraneous garbage when using with Response.BinaryWrite().  Here's where the otherwise obscure binary string functions AscB, ChrB, MidB, LeftB, and InstrB come into play.

If you were creating binary data representing FF D8 for example (a JPG header), strOut = Chr(255) & Chr(216) would be the typical code.  And this works fine for manipulating the string data and inspecting it too.  You can even save that to a file correctly.   But to Response.BinaryWrite() this looks more like ChrB(255) & ChrB(0) & ChrB(216) & ChrB(0).  The browser will see the extra data anf become confused.  If instead you use only ChrB to build the strings (and only AscB, MidB, etc. to inspect and manipulate them), everything is fine.

Once you overcome the Response.BinaryWrite() obstacle, you have to make sure the browser sees what it is supposed to.  Your ASP file should be written with a text editor such as NotePad.EXE, so that FrontPage does not keep doing you an unwanted favor and inserting obligatory HTML tags.  Right click the file to be edited in FrontPage Explorer and choose Open With, to over-ride FrontPage.  Your ASP should include no HTML tags.  For example:

<%
' Code goes here to put JPG thumbnail data into strBuffer as normal character string

' Embed reference to this ASP from your HTML in an <IMG SRC=> tag.
' Now tell the browser what's coming...
  Response.Buffer = TRUE
  Response.Expires = 0
  Response.Clear
  Response.ContentType = "image/jpeg"
' Actually you can skip these two...
  Response.AddHeader "Content-Length", len(strBuffer)
  Response.AddHeader "Content-Disposition", "inline"
' Now we create the modified (byte) string...

' Warning - this is SLOW AS MOLASSES!!!
  strOut = Empty
  For i = 1 to Len(strBuffer)
    strOut = strOut & ChrB(Asc(Mid(strBuffer,i,1)))
  Next
  Response.BinaryWrite strOut

' Thats all, folks...
  Response.End

%>

Go back to top.

 


Entire contents Copyright (C) 1994-2015 Brad Berson and Bytebrothers Internet ServicesAnim Plug
Page updated February 12, 2009.  See Terms and Conditions of use!