Installing the FrontPage Server Extensions

Upgrading the Server Extensions
Installing the FrontPage Server Extensions on Windows

Installing the FrontPage Server Extensions on UNIX

Installing the HTML Administration Forms


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.
    • If you choose the interactive operation, fp_install will prompt you for the UNIX user ID and group ID of each root web and sub-web that you have upgraded. 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 and suid the Server Extensions CGI executables in each web to be owned by the specified user and group.   If you are running the FrontPage Apache patch server this step is not necessary because there is only one centralized copy of the Server Extensions CGI executables instead of copies in each web.
    • If you choose the script option, a script will be generated that does all the necessary chown and chmod operations using fpsrvadm.exe. Before running the script, however, you must fill in the UNIX user IDs and group IDs to associate with each web.
  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, versions of the FrontPage Server Extensions earlier than version 3.0 modified the Web server's configuration file to mark directories containing the Server Extensions CGI programs as "executable." This was required whenever a FrontPage user remotely created a new FrontPage sub-web, because in addition to creating a new content area, creating a new sub-web also made new copies of the Server Extensions CGI executables in the new web.

Since the FrontPage Server Extensions run as "www" and the Web-server configuration file is owned and modifiable only by "root," and because the Server Extensions executables typically run as the user account of the owner of the website (or the "www" user if not using the SUID/SGID configuration), the Server Extensions cannot modify the server configuration file and thus have been unable to remote create new sub-webs. Instead the FrontPage Server Administrator had to be manually run as "root" on the host computer to modify the Web server's configuration file, increasing the server administrator's workload.

FrontPage 98 offers a new patched Apache server that requires only 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.

Note that use of the FrontPage Apache patch is optional, and the FrontPage Server Extensions will function in the Apache environment without the patch. Without the patch, however, users of the FrontPage Explorer will not be able to create new sub-webs, as is the case with other UNIX server types. With the patch, the Server Extensions will automatically use the security SUID/SGID model and users will be able to remotely create new subwebs. Without the patch, the FrontPage Server Extensions should be configured for SUID/SGID operation for maximum security.

The FrontPage 98 Apache patch supercedes the FrontPage 97 Apache script alias patch that was distributed with the FrontPage 97 WPP Kit. While the FrontPage 98 Server Extensions continue to support the FrontPage 97 Apache patch with a server type of "apache-wpp", the recommended configuration for the FrontPage 98 Server Extensions on Apache is to use the FrontPage 98 Apache patch for increased security.

FrontPage Apache Patch Security Considerations

The FrontPage Apache patch consists of two parts:

Because the fpexe stub program must be suid root to be able to change user IDs to the owner of the web, numerous security checks are performed in order to prevent this stub program from being used as a security hole. Checks are performed to validate:

The 128 byte key value is generated dynamically when the web server is initialized and stored for validation purposes in a suidkey.* file that is readable and writeable only by root and is stored in a directory that is readable only by root.  The suidkey.* file can be written with root-only permissions because the web server process runs as root during initialization, and only switches to another user ID (such as "www") after initialization is completed.  The suidkey.* filename suffix is the process group ID of the web server.

The contents of the dynamic key value are generated during web server initialization based on a permutation of the output of the process status (ps) command, and are then XOR'ed with the contents of an administrator-controlled custom key file stored in /usr/local/frontpage/currentversion/apache-fp/suidkey.  This custom key file must exist, be owned and readable only by root, and contain at least 8 bytes of data.  The contents of the custom key file should be changed regularly by the server administrator and the server restarted to protect the key value.

When a request is processed by the FrontPage Apache module to invoke the FrontPage Server Extensions CGI executables, the module performs preliminary validation of the request and redirects the request to the fpexe stub program.  The 128-byte key value generated when the server was initialized is passed to fpexe through a pipe and thus is not visible in the program environment.  The 128-byte key value is read by fpexe from the pipe, and then compared to the contents of the dynamically generated suidkey.* file that was created when the web server was initialized.  Since fpexe is suid root it is capable of accessing the contents of the suidkey.* file.  Assuming that the suidkey.* file still has correct permissions (readable only by root in a directory readable only by root), and assuming that the 128 byte key value matches, then fpexe performs additional checks to validate the user ID, the group ID, and ownership of the target FrontPage Server Extensions CGI executables.  If all checks pass then fpexe switches the user and group IDs to that of the web content owner and then runs the FrontPage Server Extensions CGI executables.  If any of these checks fail, an error is written to the web server log and the Server Extensions are not run.

Note that the FrontPage Apache module's security checks do not replace the web server's .htaccess file security system. Both systems work together to ensure security for the FrontPage web.  The web server's .htaccess security protects remote access to the web content by validating that the user of the FrontPage Server Extensions is a registered browser, author or administrator of the web (this process is as described in FrontPage Security on UNIX-based System).  In addition to this normal level of security checking, the FrontPage Apache module's security checks ensure that the fpexe program is not used to gain unauthorized root access to the web server machine.

Because suid root programs are of concern to server administrators, Microsoft makes the source code to the FrontPage Apache module and the fpexe stub program available for review.  The latest source code is contained in the FrontPage 98 Server Extensions download kit, and is also available for convenient browsing in an appendix of this document.  The source code contains many comments to explain the checks that are performed and recovery actions that should be taken if an error denoting an insecure configuration is logged by the FrontPage Apache module or fpexe.

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/fpexe, 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.

    A default custom key file is created as /usr/local/frontpage/currentversion/apache-fp/suidkey and is automatically chown'ed and chmod'ed to the appropriate permissions.  The default custom key value is dynamically generated, but for the best protection this key value should be changed on a regular basis and the server restarted.

  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.
    • If you choose the interactive operation, change_server.sh will prompt you for the UNIX user ID and group ID of each root web and sub-web that you have upgraded. For each FrontPage web, change_server.sh will chown all the FrontPage-created directories and content in each web to be owned by the specified user and group and it will chmod the content.
    • If you choose the script option, a script will be generated that does all the necessary chown and chmod operations using fpsrvadm.exe. Before running the script, however, you must fill in the UNIX user IDs and group IDs to associate with each web.

Note for FrontPage 98 Beta and FrontPage 98 Initial Release Apache Patch Users

The FrontPage 98 Beta and the initial release of the FrontPage 98 client CD contained a version of the FrontPage Apache patch that had a security bug.  The bug was that fpexe did not perform enough checks to ensure that fpexe could only be invoked through the web server and that only the FrontPage Server Extensions CGI executables could be run as a result of accessing fpexe.

This bug was fixed in the FrontPage 98 UNIX Server Extension download kits posted as of 10/21/97 on the Microsoft FrontPage website.   The FrontPage 98 Beta UNIX server extensions, and any download kits dated before 10/21/97 should not be used, rather new kits should be downloaded from the website.   An additional check is that the version string reported by the server should be FrontPage 3.0.3 or higher.  Any version prior to 3.0.3 should be replaced with a more recent download.

To upgrade a server that is running an older version of the FrontPage 98 Server Extensions, download the new kit and re-run change_server.sh.  The change_server.sh script will replace the files affected by the bug (fpexe and the Apache daemon itself), generate a default custom key file, and set permissions appropriately.

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.