How to administer Win32 Apache web sites using FrontPage 2000

Abstract

This article shows how it is possible to administer an Apache web server running under Windows NT with FrontPage 2000. For Apache running on Unix boxes, this setup is well-known and extensively described, but not for Win32 systems.

The problem

On of my latest jobs was to reorganize our corporate web sites. Five different web sites were running on five different machines under Windows NT, IIS 4.0, with the FrontPage extensions installed. As administration tool, the webmasters use FrontPage 2000. The idea was to have all sites served by a single machine.

Why Apache ?

For personal purposes, I have been using the Apache web server for a few years. My web server box was running under Linux, and I found that the Apache server was easy to maintain (the configuration is stored in text files), the security is fine-tunable, and virtual hosts are quite easy to set up. In addition, one can install the Microsoft FrontPage extensions to administer the sites served by Apache. This is why I thought that Apache would be a good software for my company.
Unfortunately, on my company’s web servers, we have some win32 executables running as cgi programs. It was not possible for us to rewrite all these programs to run under Linux. So I thought about using the win32 version of Apache. But, there are no FrontPage extensions for the win32 Apache...

A solution...

I installed a Windows NT machine, with Apache 3.12 running as a service, serving our five web sites using the virtual hosts setup. For all these hosts, Apache listens to port 80.
On the same machine, I also installed the Microsoft FrontPage Personal Server, running as a service (I used the SRVANY program that comes with the NT resource Kit), serving my five sites on port 3145 (an arbitrary choice) via the local network. I have set up a very strict security on these sites, so that a normal user cannot browse these sites on port 3145.
In addition to the Microsoft FrontPage Personal Server setup, I’ve added the FrontPage extensions. With this setup, I am now able to easily maintain my web pages, on my five sites, with FrontPage 2000. When I open a site for administration, I simply open a web using the http://server:3145/site syntax. This works fine, and my webmasters are happy!

Mapping FP web names to Apache directories

One of my FrontPage webs is named 'public'. On the default page (default.html), I have put a hit counter. If we look at the html code generated, we will have these image properties:

http://theta.mscgva.ch/_vti_bin/fpcount.exe/public/?Page=default.htm|Image=4|Digits=8.

The apache server does not know what /public is. As a consequence, the hit counter never gets incremented. This problem is easily solved with an Alias directive (in the httpd.conf file). For example:

<VirtualHost 195.141.192.150>
    ServerName theta.mscgva.ch
    ServerAdmin webmaster@mscgva.ch
    DocumentRoot d:/www/public
    ErrorLog logs/gvapub-e.log
    CustomLog logs/gvapub-a.log common
    # The Alias directive provides a map between the frontpage personal 
    # server web name and the physical location of the files in Apache.
    # In this case, "public" is the name of the FP web.
    # This setup is important for the fpcounter to run correctly.
    Alias /public d:/www/public
</VirtualHost>


The_vti_bin/shtml.exe problem

So far, so good. One of the webmasters created a page with a search search form on it. When he tested the page, he received a FrontPage error, which appeared in the server's application event log:

Microsoft FrontPage Server Extensions:
Error #20018 Message: INI file "" section "Port 80" not found.


In fact, the shtml.exe program is looking for parameters described in a configuration file, frontpg.ini, that resides in the system root directory (c:\winnt in my case), and which looks like this (remember that my FrontPage Personal Web Server serves port 3145):

[FrontPage 3.0]
FrontPageRoot=C:\Program Files\Microsoft FrontPage
UILangAbbrev=enu
NoAbsoluteFileResults=1
NoServerFileResults=1
BotCacheDir=C:\Program Files\Microsoft FrontPage\BotCache
[Ports]
Port 3145=
[Port 3145]
frontpageroot=C:\Program Files\Microsoft FrontPage\version3.0
requiressl=disabled
authoring=enabled
servertype=frontpage
serverconfig=C:\FrontPage Webs\Server\conf\httpd.cnf


And, in fact, no section describes port 80. So I modified the file and added a section for port 80 (in bold):

[Ports]
Port 3145=
Port 80=
[Port 3145]
frontpageroot=C:\Program Files\Microsoft FrontPage\version3.0
requiressl=disabled
authoring=enabled
servertype=frontpage
serverconfig=C:\FrontPage Webs\Server\conf\httpd.cnf
[Port 80]
frontpageroot=C:\Program Files\Microsoft FrontPage\version3.0
requiressl=disabled
authoring=disabled
servertype=frontpage
serverconfig=C:\FrontPage Webs\Server\conf\dummy.cnf
...


This was the trick! But then, there was a problem with the file produced by the shtml.exe program: the web server referenced came from the serverconfig file ServerName entry. As an example, if the FrontPage server name sitting on port 80 was MYSERVER, the search result page produced was : http://MYSERVER/msc/_vti_bin/shtml.exe/search.htm, and, of course, the server was not found! This is not supportable with the concept of Virtual Hosts, in which the server name, must dynamically vary.
And here comes another trick (I searched a lot!): in the httpd (port 80) configuration file (C:\FrontPage Webs\Server\conf\dummy.cnf in my case), I just commented out the ServerName line. The result is that, to build its pages, shtml.exe takes as server name, the name of the server that called the program. Shtml.exe is now perfectly compatible with the Apache virtual hosts...