Installing the FrontPage Server Extensions

This topic describes installing the FrontPage Server Extensions on a Web server machine. The FrontPage Server Extensions are installed:

The FrontPage Server Extensions are installed in two steps. First the Server Extensions are copied to the host computer’s hard drive by the installer program into a single FrontPage directory. Next, the Server Extensions stub DLLs or stub CGI executables are installed on the root web of each virtual server on the host computer and, if sub-webs exist on the server, on each sub-web. During Server Extension installation, you can specify on which virtual servers to install the Server Extensions.

After the Server Extensions are copied to a host computer’s hard drive, they must be added to each new FrontPage web that is created. On some platforms this is initiated automatically by the FrontPage client setup program. On other platforms, it must be done as a separate administrative task.

For a full description of how the FrontPage Server Extensions are stored in a FrontPage web, see The FrontPage Server Extensions on UNIX Web Servers and The FrontPage Server Extensions on IIS.

Upgrading the Server Extensions

Each FrontPage client release is accompanied by a new Server Extensions release that supports the new features of the client. For example, FrontPage 98 is accompanied by a new FrontPage 98 Server Extensions release. It is always most effective to use the most up-to-date versions of the FrontPage client and the Server Extensions.

Each new release of the Server Extensions is backward compatible with previous FrontPage client versions so that it continues to support the client's functionality at each earlier level. For example, a FrontPage 97 client can open and edit a FrontPage web from a Web server that has the FrontPage 98 Server Extensions installed, with no loss of functionality in the FrontPage 97 client. However, the client will not be able to access new Server Extensions functionality added for the FrontPage 98 client, such as applying themes to a FrontPage web or creating and saving a FrontPage web structure.

Installing the FrontPage Server Extensions on Windows

On the Microsoft Windows platform, the following products include, as all or part of their installation, the FrontPage 98 Server Extensions:

Microsoft Visual InterDev also relies upon the FrontPage Server Extensions and includes them in the Visual InterDev server-side setup program.

What Gets Installed?

When you install the FrontPage Server Extensions, the following components are installed:

Installing the Server Extensions

These installation instructions are for the stand-alone FrontPage Server Extensions that are downloadable from the FrontPage Web site. The FrontPage client is a separate CD-ROM based setup that includes both the FrontPage Server Extensions and the FrontPage client. To install from the CD-ROM simply insert the disk into your CD-ROM drive and click on the FrontPage 98 option.

Note: You must be an NT system administrator to install the FrontPage Server Extensions.

The stand-alone Server Extensions are installed by running a self extracting executable. You can download this program for your language at http://www.microsoft.com/frontpage/ . You can also find the Server Extensions setup programs on the FrontPage 98 CD-ROM, in the folder \ServExt. This folder contains self extracting setup programs named in the form fp98ext_processor_lang, where processor is the machine’s processor type and lang is a three-letter code for the language of the server extensions. For example, the German FrontPage Server Extensions setup program for an Intel x86 series processor is on the FrontPage CD-ROM in \ServExt\fp98ext_x86_deu.exe.

  1. To start installing the FrontPage Server Extensions, run the Server Extensions setup program for your language and processor type.

    The Server Extensions are copied to the folder C:\Program Files\Microsoft FrontPage\version3.0. While the Server Extensions are being copied to C:\Program Files\Microsoft FrontPage\version3.0, your Web server is stopped to make sure that files are not locked by the running Web server. As soon as the copy is complete, the Web server is started and remains running for the remainder of the installation process.
  2. On a multi-hosted machine, the Multi-hosted Server dialog box is displayed. Select the virtual servers on which the FrontPage Server Extensions should be installed and click OK. On a single-hosted server the FrontPage Server Extensions are automatically installed on the single content root of the server and no dialog box appears.
  3. You are prompted for the name of a new FrontPage administrator account.

    If you are installing on an IIS server, this account must already exist, and you are not prompted for a password. If you are installing on a Netscape or WebSite server, you are prompted for a name and password and the account is created.

    You can add other administrator accounts after installing the Server Extensions using the Permissions command in the FrontPage Explorer.
  4. The stub Server Extensions are installed on each root web and sub-web.

Installing the Server Extensions on each FrontPage web may take several minutes and may increase the CPU load on your computer. If this is a new installation of the FrontPage Server Extensions, each page’s contents are parsed to:

FrontPage implements web security on IIS by changing the access-control lists (ACLs) for all files and directories in each FrontPage web. Installing FrontPage always modifies the ACLs of the Server Extensions stub executables contained in the _vti_bin directory in each web. A new installation of FrontPage will additionally modify the ACLs of the web content files, but an upgrade of an existing installation of the Server Extensions will not modify the content file ACLs and consequently will leave the security settings at a less secure level than the default settings of FrontPage 98. The ACLs of the web content can be upgraded to the level of FrontPage 98 by using the Check and Fix option of the FrontPage Server Administrator utility.

In addition to modifying the security ACLs of the web content files, FrontPage modifies the ACLs of any system DLLs that are used as a result of a FrontPage DLL call, to ensure that the system DLLs will have the correct level of permissions to run under any administrator, author, or end-user’s account. For the complete set of ACLs set on FrontPage files, along with a list of the entire contents of a FrontPage installation, see FrontPage Windows NT File Permissions. For a discussion of security considerations when installing the Server Extensions and the reasons why the ACLs of the system DLLs must be modified, see FrontPage Server Extensions: Security Considerations.

IIS 4.0 Installation Considerations

If you are using IIS 4.0, you must use the FrontPage 98 Server Extensions. Previous versions of the FrontPage Server Extensions are not compatible with IIS 4.0. The IIS 4.0 installer program will ensure that any previous versions of the FrontPage Server Extensions are upgraded to the FrontPage 98 Server Extensions when IIS 4.0 is installed.

The FrontPage Server Extensions are installed automatically as a part of the Minimum and Typical IIS 4.0 setup. However the Server Extensions are added to virtual servers based on the following rules:

There are two ways to add the FrontPage Extensions to a virtual server with IIS 4.0:

Installing the FrontPage Server Extensions on UNIX

The FrontPage 98 Server Extensions for UNIX platforms are available for downloading at http://www.microsoft.com/frontpage . The installation package for a UNIX platform consists of three files: the installation script fp_install.sh, the Apache server upgrade script change_server.sh, and the Server Extensions in a tar file. The tar file is named fp30.platform.tar.Z, where platform is the UNIX platform to which the Server Extensions are being installed, as in fp30.linux.tar.Z.

The files fp30.platform.tar.z (or fp30.platform.tar.gz), fp_install.sh, and change_server.sh are the complete Server Extensions package. Unlike previous releases of the Server Extensions that offered the Web Presence Provider's Kit, there are no additional utility or configuration script downloads required for the FrontPage 98 Server Extensions.  The contents of the former Web Presence Provider's Kit are included.

You can install the FrontPage Server Extensions to the following types of Web servers:

What Gets Installed?

When you install the FrontPage Server Extensions, the following components are installed:

UNIX Setup Preview

Depending on how the content on your server is organized you may want to install the FrontPage Server Extensions in one of the following ways:

Using the Installation Script

The FrontPage 98 Server Extensions installation script is fp_install.sh. You must be logged on as root to run this script.

  1. You are prompted to back up the FrontPage installation directory, the server configuration file directory, and any content before installing the FrontPage 98 Server Extensions, and you are prompted for a Server Extensions directory.

    By default, the FrontPage Server Extensions are installed in the directory /usr/local/frontpage/. You can accept the default or specify another location. If you select another location, a symbolic link will be created from /usr/local/frontpage/ to the directory you specified.
  2. You are prompted to untar the FrontPage Server Extensions tar file, fp30.xxx.tar.Z. If the tar file is not in the default directory, you are prompted for its location.
  3. If the Web server currently has the FrontPage Server Extensions, it is upgraded to the FrontPage 98 Server Extensions. The stub Server Extensions are installed on the root web and each sub-web.
  4. FrontPage 98 has a new security model on UNIX in which each FrontPage web can be owned by single UNIX user ID and group ID. In order for this to work correctly, the ID of the Server Extensions on each FrontPage web must be set to the ID of the user who owns the web, and the content needs to have write-permissions by that user. To make this model secure, the content must only be owned and writeable by that user. The fpsrvadm.exe program can do both of these operations for you.

    After upgrading all servers to the FrontPage 98 server extensions, you can specify to set up the security of your FrontPage webs interactively or you can have fp_install generate a script to perform the operation.
  5. If the Web server does not have the FrontPage Server Extensions, you are prompted to install them on the server’s root web.

    Before installing the root web you are prompted for a FrontPage web administrator name and password. You will not need this name and password again during this installation, but will need to use it when creating new FrontPage webs or adding other FrontPage web administrators from the FrontPage Explorer. After installing the root web, you are prompted for your system’s local character encoding and default language. See Administering the FrontPage Server Extensions for details.

  6. After installing the stub Server Extensions on the root web of a server that does not have the Server Extensions, you are prompted to install the stub Server Extensions in each sub-web.

    During installation of the stub Server Extensions on each sub-web, you are prompted for the name of each sub-web. If the name is of the form ~webname, then webname is used as the name of the sub-web’s owner. If not, you are prompted for the name of the owner.

    For each sub-web that you choose, you are also prompted for any missing information (such as port number) and then the stub Server Extensions are installed on the sub-web.

    While installing a new root web and new sub-webs, fp_install will prompt you for each web’s user ID and group ID. (If installing a per-user sub-web, then the install script infers the user ID from the web name.) For each FrontPage web, fp_install will then chown the content in each web to be owned by the specified user and group and it will chmod the content. If the FrontPage web is not the FrontPage Apache patch server, fp_install will also chown the Server Extensions.
  7. After installing on the root web and on all sub-webs, you are prompted to install the FrontPage 98 Server Extensions on any virtual webs. If you indicate that you want to install on virtual webs, the script displays a list of the virtual webs on your server (as indicated in the server configuration file).

    For each virtual server that you choose, you are prompted for any missing information (such as port number) and the stub Server Extensions are installed on the root web and any sub-webs of each virtual server.

    While installing a new virtual root web and sub-webs, fp_install will prompt you for each web’s user ID and group ID. (If installing a per-user sub-web, then the install script assumes the user ID from the web name.) For each FrontPage web, fp_install will then chown the content in each web to be owned by the specified user and group and it will chmod the content. If the FrontPage web is not the FrontPage Apache patch server, fp_install will also chown the Server Extensions.

When the installation is finished, if it is a new installation of the FrontPage Server Extensions, each page’s contents are parsed to:

FrontPage implements web security on UNIX by making entries in access files throughout the web’s content, and by maintaining files that contain lists of users and passwords for the FrontPage web. FrontPage also modifies the Web server’s configuration file, unless you are running the FrontPage patched Apache server.

For a complete list of the entire contents of a FrontPage installation, see Files and Permissions for UNIX Servers. For a discussion of security considerations when installing the Server Extensions, see FrontPage Server Extensions: Security Considerations.

About the FrontPage Apache Patch

On Apache Web servers, previous versions of the FrontPage Server Extensions have modified the Web server's configuration file to mark directories containing the Server Extensions as "executable." Since the FrontPage Server Extensions run as "www" and the Web-server configuration file is owned and modifiable only by "root," the FrontPage Server Administrator had to be manually run as "root" on the host computer to do this. This prevented FrontPage administrators from remotely creating FrontPage webs, because the Web server's configuration file would have then had to be owned by "www," which would have potentially compromised the host system's security.

FrontPage 98 offers a new patched Apache server that makes it possible to install a single version of the FrontPage Server Extensions, without stub versions of the Server Extensions in each FrontPage web. This makes it unnecessary to write to the Web server’s configuration file when creating new FrontPage webs, allowing creation of FrontPage webs remotely, using the FrontPage Explorer.

With the Apache patch, it is also impossible to run the FrontPage Server Extensions from any program (including unfriendly CGI executables) except the Apache web server or another program run as root. In order for the server extensions to be run, they must receive a 128 bit key in their environment. This key is compared to a file that is created by the Apache web server when it starts up and that is read only by root. Furthermore, this file is keyed off the Apache web server’s process group ID.

An Apache server running the FrontPage Apache patch protects access to Web content using the standard method described in FrontPage Security on UNIX-based System. If an attempt is made to invoke the FrontPage Server Extensions, the FrontPage stub executable is invoked by the patched Apache server, with an 128-bit password. If this password does not match one in a secure file owned by root, the attempt to run the FrontPage Server Extensions fails. Otherwise, the stub executable suids itself to the owner of the FrontPage web and then invokes the FrontPage Server Extensions.

To Install the Apache Patch

There are two ways to convert your current Apache web server to the FrontPage patched Apache web server.

The first method is to manually compile-in the provided patches and module into your current Apache server. To do this, follow the instructions distributed with the Apache server. Even if you do manually compile in the provided patches and module, you should run the script described below to correctly set up FrontPage to work the with the new server.

The second method for converting your current Apache web server to the FrontPage patched Apache web server is to use the script described below, which will install a pre-compiled version of the Apache server onto your system.

This script will step the user through upgrading existing servers and installing new servers and webs. To run the script, you must be running as root. The script will run with a umask of 002. For FrontPage to work once the new server is installed, the FrontPage Apache stub, in /usr/local/frontpage/version3.0/apache-fp/_vti_bin/fp.exe, must be owned by and SUID’d to root. The script does this for you.

  1. Back up your current Apache server directory.
  2. Back up the FrontPage installation directory, server configuration file directory, and all web content.
  3. Start the script change_server.sh.
  4. When prompted, indicate the location of your current Apache server.
  5. The script checks to make to sure the server has not already been upgraded. It then moves the old Apache daemon to the file httpd.orig and copies the new FrontPage patched Apache server to the correct place.

    Next, the FrontPage configuration files in /usr/local/frontpage are modified to refer to the new server. For each Apache server that has the FrontPage Server Extensions and that has not already had the Apache patch installed, you will be prompted to install the patch.

    Installing the Apache patch changes the configuration file in /usr/local/frontpage and deletes any fake configuration file (from the FrontPage 97 WPP Kit) if necessary. Finally, it calls the FrontPage Server Administrator to upgrade the web content area. This removes the Server Extensions stub executables, which are no longer needed.

  6. You can specify to set up the security of your FrontPage webs interactively or you can have change_server.sh generate a script to perform the operation.

Installing the HTML Administration Forms

The FrontPage 98 Server Extensions package includes HTML Administration Forms. These are HTML forms that can be used remotely to install and administer the FrontPage Server Extensions from a standard Web browser. These forms are copied to your Web server’s hard drive as a part of the FrontPage Server Extensions installation.

Because of the security implications of making remote FrontPage administration available from Web browsers, the FrontPage installer does not make the HTML Administration Forms active and accessible to browsers when the forms are installed. After understanding the security implications, you can make the HTML Administration Forms active on a server following the instructions below.

Note that activating or using the HTML Administration Forms is optional. All FrontPage Server Extensions administration can be done using the FrontPage Server Administrator application or the Server Administrator command line tools running directly on the machine that is running the Web server.

Administering FrontPage remotely from a browser increases the risk that an unauthorized person could gain access to the FrontPage webs on your server, because the FrontPage security settings for the FrontPage webs on the server can be modified or loosened if access to the HTML Administration Forms is gained. Additionally an unauthorized user could, with the HTML Administration Forms, delete FrontPage webs or otherwise deny access to them. To prevent this, the following precautions are recommended:

Activating the HTML Administration Forms on IIS 2.0 and IIS 3.0

You should run the HTML Administration Forms over a secured port. On IIS it is not possible to use a secured port unless the server has a security certificate installed. If you do not already have a security certificate before activating the HTML Administration Forms, use the Key Manager application to make a security certificate request, submit the request to a key authority, and then use the Key Manager application to install the certificate returned by the key authority. The IIS documentation contains more details on this process.

Once you have a security certificate, the following steps will activate the HTML Administration Forms for remote use.

  1. Determine the NT machine account (or group of accounts) that will be granted access to the HTML Administration Forms.

    This account should be a member of the machine’s Administrators group. If necessary, create a new account using the Windows NT User Manager. Depending on the machine’s account configuration, the Administrators group may be an easy to use alternative to multiple individual machine accounts.
  2. Open the Windows Explorer at the hard drive location of the HTML Administration Forms, which is C:\Program Files\Microsoft FrontPage\version3.0\admin by default. Select the \isapi folder, choose Properties from the File menu, select the Security tab, and click Permissions.
  3. In the Directory Permissions dialog, using the Add and Remove buttons, update the Name list of authorized users and groups.

    Remove all users and groups that are not authorized. In particular make sure that no group that is added to the list contains the IUSR_machinename anonymous access account, and that any wide-access accounts such as EVERYONE are removed.
  4. In the Name list, add the machine’s SYSTEM account.

    This account is required to allow IIS to access the file during the security validation process.
  5. For each user or group in the Name list, change Type of Access to Read.
  6. Click Replace Permissions on Subdirectories and Replace Permissions on Existing Files, and click OK to accept the changes. Click OK again to dismiss the folder properties dialog.

Next you will create a virtual root for the HTML Administration Forms

  1. Start the IIS Internet Service Manager application.
  2. Double-click on the WWW service to edit the service properties.
  3. Select the Directories tab, and click Add.
  4. In the Directory field, enter the location of the isapi folder, usually C:\Program Files\Microsoft FrontPage\version3.0\admin\isapi.
  5. In the Alias field, type "/fpadmin"
  6. For Access, click Read and Execute.
  7. Click Require secure SSL channel
  8. Click OK twice to accept the changes.

The forms are now usable for remote administration using a URL such as https://mymachine/fpadmin/fpadmin.htm.

Activating the HTML Administration Forms on IIS 4.0

You should run the HTML Administration Forms over a secured port. On IIS it is not possible to use a secured port unless the server has a security certificate installed. If you do not already have a security certificate before activating the HTML Administration Forms, use the Key Manager application to make a security certificate request, submit the request to a key authority, and then use the Key Manager application to install the certificate returned by the key authority. The IIS documentation contains more details on this process.

Once you have a security certificate, you can enable the HTML Administration Forms either as a separate IIS web site or as a virtual directory on an existing web site. The advantages of using a separate site is that a separate IP address can make the forms harder to discover, and a separate site allows additional security settings to be enabled such as distinct non-standard port numbers. The disadvantage of using a separate web site is that an additional IP address is required for the machine. See To create a separate web site to host the HTML Administration Forms or To create a virtual directory to host the HTML Administration Forms on an existing web site.

To create a separate web site to host the HTML Administration Forms:

  1. Prepare the access permissions on the Administration Form files by following steps 1 through 6 of the Activating the HTML Administration Forms on IIS 2.0 and IIS 3.0 procedure.
  2. Start the IIS Internet Service Manager application and open the IIS and machine’s folders.
  3. Right click on the icon labeled with the machine name and click Create New Web Site.
  4. In the New Web Site Wizard, fill in the Description field with the name of the site, for example "FrontPage 98 Administration Forms", and click Next.
  5. Select the IP Address to use for this site. The IP Address must have been pre-configured before running the New Web Site Wizard. Do not use the TCP Port field because the Administration Forms will only be accessed through a secure port. Click Next to continue.
  6. Enter the path to the HTML Administration Form files, usually C:\Program Files\Microsoft FrontPage\version3.0\admin\isapi, and make sure that the Allow anonymous access to this web site checkbox is turned off. Click Next.
  7. Click both Allow Read Access and Allow Execute Access (includes Script Access) and click Finish.
  8. Right click on the new web site icon created in the left pane, which will be labeled with the name typed in for step 4. Click Properties.
  9. Select the Web Site tab, and type in a non-standard port number in the SSL port field, for example 8234.
  10. Select the Directory Security tab, and click the Secure Communications Edit button. Click the Require Secure Channel checkbox and Click OK.
  11. Add any TCP/IP Access Restrictions that are desired.
  12. Click OK to accept the changes.

The forms are now usable for remote administration using a URL such as https://machinename:8234/fpadmin.htm, where machinename corresponds to the IP address entered in step 5 and 8234 corresponds to the port number entered in step 9.

To create a virtual directory to host the HTML Administration Forms on an existing web site:

  1. Prepare the access permissions on the Administration Form files by following steps 1 through 6 of the Activating the HTML Administration Forms on IIS 2.0 and IIS 3.0 procedure.
  2. Start the IIS Internet Service Manager application and open the IIS and machine’s folders.
  3. Right click on the web site icon that will be used to host the HTML Administration Forms, such as Default Web Site. Click Create New Virtual Directory.
  4. In the New Virtual Directory Wizard, fill in the Alias field with the alias name of the HTML Administration Forms, such as "fpadmin", and click Next.
  5. Enter the path to the HTML Administration Form files, usually C:\Program Files\Microsoft FrontPage\version3.0\admin\isapi, and click Next.
  6. Click both Allow Read Access and Allow Execute Access (includes Script Access) and click Finish.
  7. Right click on the new fpadmin virtual directory icon, and click Properties.
  8. Select the Directory Security tab, and click the Password Authentication Method box’s Edit button.
  9. Make sure that the Allow Anonymous checkbox is not checked, and that one or both of Basic Authentication or Windows NT Challenge/Response is checked, and click OK.
  10. Click the Secure Communications box’s Edit button.
  11. Click Require Secure Channel, and click OK.
  12. Add any TCP/IP Access Restrictions that are desired.
  13. Click OK to accept the changes.

The forms are now usable for remote administration using a URL such as https://machinename/fpadmin/fpadmin.htm.

Activating the HTML Administration Forms on Other Servers

When using servers other than IIS, use the server’s administration tool or configuration files to configure a new virtual directory for the HTML Administration forms, and configure the appropriate security settings.

In addition to configuring a virtual root and the appropriate access controls, execute permissions must be granted to the scripts subdirectory of the forms directory in order to run the CGI application that actually performs the administration command on the server.