Administration of the Microsoft FrontPage Server Extensions

General FrontPage Server Extensions Administration

• The fpsrvadm Utility
• HTML Administration Forms
• The fpremadm Utility
• Using FTP To Copy a FrontPage Web
• Using the FrontPage Configuration File
• Language Settings in FrontPage Webs
• Recalculating FrontPage Webs
• Setting Up Your E-mail Transport

Windows FrontPage Server Extensions Administration

• The FrontPage Server Administrator Utility
• The iisadmin Utility
• The admin.pl Utility
• Using FrontPage with Microsoft Index Server
• Creating a New Virtual Server on Windows NT
• IIS Security and Permissions Management Strategies
• IIS 4.0 and the Server Extensions
• Microsoft Visual SourceSafe 5.0 Integration

UNIX FrontPage Server Extensions Administration

• Creating a New Virtual Server on UNIX

The fpsrvadm Utility

The fpsrvadm utility installs, updates, removes, and checks the FrontPage Server Extensions on FrontPage root webs and sub-webs, and performs other administrative FrontPage web operations. fpsrvadm can be run even when the Web server is not currently running (although the administration service for servers that use one may need to be running).

The fpsrvadm utility is a command line application used on both UNIX and Windows NT.

When you invoke fpsrvadm, you supply an operation, of the form -operation <value> and a set of command line options in the form -option <value>. For example, the following fpsrvadm command upgrades the FrontPage Server Extensions on port 80 of the virtual server sample.microsoft.com:

Each option has a short form, shown below. The sample command above in short form is:

fpsrvadm includes the following operations:

The fpsrvadm options are:

Install

fpsrvadm -o install -p <nnnn> -m <hostname>
    -u <username> -pw <password>
    -t <servertype> [-s <server config file> [ -w <webname> ]
    [ -xu <UNIX username>] [ -xg <UNIX groupname>] [ -n]

Installs the FrontPage Server Extensions on port <nnnn> of virtual server <hostname>, using the specified administrator name and password. If <webname> is specified, the Server Extensions are installed on the named FrontPage sub-web. Otherwise, the Server Extensions are installed on the root web of the specified virtual server. For any <servertype> except website and msiis, you must specify a server configuration file, using the -s switch.

On UNIX, if -xu and -xg are specified, the FrontPage directories and Server Extensions files along with the web's content are chowned and chmoded to <UNIX username> and <UNIX groupname>. The -n switch specifies to only chown and chmod the FrontPage directories and Server Extensions files, not the web content files. For a discussion of UNIX server security with FrontPage see the FrontPage Security on UNIX-based Systems.

To install the server extensions on Windows NT with an IIS web server, use the following options. The password option is not necessary because with IIS the passwords for accounts are specified in the NT account list administration tools, not in the web server or FrontPage administration tools.

fpsrvadm -o install -t msiis -p 80 -m sample.microsoft.com -u adminaccount

To install the server extensions on an Apache Web server that is running the FrontPage apache patch, use the following command line:

fpsrvadm -o install -t apache-fp -s /usr/local/apache/conf/httpd.conf -p 80 -m sample.microsoft.com -u adminaccount -p adminpassword -xu www -xg www

Upgrade

fpsrvadm -o upgrade -p <nnnn> -m <hostname> [ -w <webname> ]
    [ -xu <UNIX username>] [ -xg <UNIX groupname>] [ -n]

Upgrades the FrontPage Server Extensions on port <nnnn> of virtual server <hostname>. If <webname> is specified, the Server Extensions are upgraded on the named FrontPage sub-web. Otherwise, the Server Extensions are upgraded on the root web of the specified virtual server, and any sub-webs present beneath that root web are also upgraded.

On UNIX, if -xu and -xg are specified, the FrontPage directories and Server Extensions files, along with the web's content, are chowned and chmoded to <UNIX username> and <UNIX groupname>. The -n switch specifies to only chown and chmod the FrontPage directories and Server Extensions files.

Uninstall

fpsrvadm -o uninstall -p <nnnn> -m <hostname>

Uninstalls the FrontPage Server Extensions on port <nnnn> of virtual server <hostname>. Uninstalling the server extensions from the virtual server's root web also uninstalls the server extensions from any sub-webs that are present beneath the root web.

Note that uninstalling the FrontPage Server Extensions does not remove content. It only removes the Server Extensions executables and accessory Server Extensions files.

Check

fpsrvadm -o check -p <nnnn> -m <hostname> [ -w <webname> ]

Checks and fixes the FrontPage Server Extensions installation on port <nnnn> of virtual server <hostname>. If <webname> is specified, the Server Extensions are checked on the named FrontPage sub-web. Otherwise, the Server Extensions are checked on the root web of the specified virtual server.

Checking the Server Extensions includes replacing missing FrontPage directories and files, and making sure all FrontPage executables are present and with the correct permissions.

Security

fpsrvadm -o security -p <nnnn> -m <hostname> -w <webname>
    -a <accesstype> -u <username> -pw <password> [-i <ipaddress>]

Sets up FrontPage web security on the FrontPage web <webname> on the specified virtual server and port, for the specified username and password. On Microsoft IIS servers, the username must be an NT account and the password is ignored if it is provided.

To add an administrator, specify the access type "administrators." To add an author, specify the access type "authors," and to add a user, specify the access type "users." To remove a user's, administrator's, or author's FrontPage web permissions, specify the access-type "remove." To downgrade the permissions granted to a particular account, the account must first be removed and then re-added with the new permissions level.

Use the optional -i switch to restrict authoring, administering, or end user access to client computers based on IP address. You can use the asterisk character "*" as a wild card in any of the four IP address sections. For example, the IP address mask 157.*.*.* specifies any IP address beginning with 157. Note that IP address restrictions are not supported by some of the server types supported by the FrontPage Server Extensions.

Chown

fpsrvadm -o chown -p <nnnn> -m <hostname> [ -w <webname> ]
    [ -xu <UNIX username>] [ -xg <UNIX groupname>] [ -n]

On UNIX only, chowns and chmods the FrontPage directories and Server Extensions files, along with the web's content to <UNIX username> and <UNIX groupname>. This guarantees the optimum FrontPage Server Extensions security on UNIX. See FrontPage Security on UNIX-based Systems for details.

The -n switch specifies to only chown and chmod the FrontPage directories and Server Extensions files, and not the web contents directories and files.

Enable

fpsrvadm -o enable -p <nnnn> -m <hostname>

Enables authoring and administering FrontPage webs on port <nnnn> of virtual server <hostname>.

Disable

fpsrvadm -o disable -p <nnnn> -m <hostname>

Disables authoring and administering FrontPage webs on port <nnnn> of virtual server <hostname>.

Recalc

fpsrvadm -o recalc -p <nnnn> -m <hostname> -w <webname>

Recalculates and repairs all internal hyperlinks in the specified FrontPage web on the specified virtual server and port. This command also re-includes pages in Include Page components, recalculates other FrontPage components (such as Search Forms and Navigation Bars), reapplies borders to any pages using borders, resets permissions on FrontPage form handler result pages, and recalculates text indices.

Putfile

fpsrvadm -o putfile -p <nnnn> -m <hostname> -w <webname>
    -f <filename> -d <destination>

Imports the file <filename> to the URL <destination> in the FrontPage web <webname> on the specified virtual server and port.

Recalcfile

fpsrvadm -o recalcfile -p <nnnn> -m <hostname> -w <webname>
    -d <destination>

Recalculates and repairs all internal hyperlinks at the specified URL <destination> in the FrontPage web <webname> on the specified virtual server and port. This command also re-includes pages in Include Page components and recalculates text indices.

Delete

fpsrvadm -o delete -p <nnnn> -w <webname> [-m <hostname>]

Deletes the  FrontPage sub-web <webname> on the specified virtual server and port. This is the only way to delete sub-webs on servers of the following types: ncsa, apache, cern. You cannot delete the root web using this command. Instead, use the Uninstall option.

Rename

fpsrvadm -o rename -p <nnnn> -w <webname> -d <destination> [-m <hostname>]

Renames the  FrontPage sub-web <webname> on the specified virtual server and port to <destination>. This is the only way to rename sub-webs on servers of the following types: ncsa, apache, cern.

SetDirExec

fpsrvadm -o setdirexec -p <nnnn> -w <webname> -d <destination>
        [-m <hostname>]

Specifies that the directory <destination> can contain executable scripts or programs in the  FrontPage sub-web <webname> on the specified virtual server and port. This is the only way to make a directory executable on servers of the following types: ncsa, apache, cern.

SetDirNoExec

fpsrvadm -o setdirnoexec -p <nnnn> -w <webname> -d <destination>
        [-m <hostname>]

Specifies that the directory <destination> cannot contain executable scripts or programs in the  FrontPage sub-web <webname> on the specified virtual server and port. This is the only way to specify that a directory cannot contain executable scripts or programs on servers of the following types: ncsa, apache, cern.

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. The home page of the HTML Administration Forms is fpadmin.htm.

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 first installed. After understanding the security implications, you can decide whether or not to make the HTML Administration Forms active on a server. For a discussion of these security implications, along with descriptions of how to install the HTML Administration Forms on IIS 2.0, 3.0, and 4.0, see Installing the HTML Administration Forms.

Installing the FrontPage Server Extensions on a New Virtual Server

1. From your browser, start the HTML Administration Forms by opening fpadmin.htm.
2. In the contents listing, choose New Virtual Server.
3. In the Virtual Host Name field, enter the name of the virtual host that will have the FrontPage Server Extensions installed.
4. In the Port Number field, enter the name of the port.
5. In the Administrator Account Username field, enter a user name. With IIS the user name can be qualified with a domain name, for example domain\username, and this value can be either a Windows NT user account name or a Windows NT group name.
6. Click Create Server.

Installing the FrontPage Server Extensions on a New Sub-web

1. From your browser, start the HTML Administration Forms by opening fpadmin.htm.
2. In the contents listing, choose New Subweb.
3. In the Virtual Host Name field, enter the name of the virtual host that the sub-web will be created beneath
4. In the Port Number field, enter the name of the port.
5. In the Subweb Name field, enter the name of the new sub-web.
6. Click Create Subweb.

Removing the FrontPage Server Extensions from a Virtual Server

1. From your browser, start the HTML Administration Forms by opening fpadmin.htm.
2. In the contents listing, choose Uninstall.
3. In the Virtual Host Name field, enter the name of the virtual host.
4. In the Port Number field, enter the name of the port.
5. Click Uninstall.

Checking and Fixing the FrontPage Server Extensions on a Virtual Server

Checking the Server Extensions includes replacing missing FrontPage directories and files, making sure all FrontPage executables are present and with the correct permissions, and removing lock files.

1. From your browser, start the HTML Administration Forms by opening fpadmin.htm.
2. In the contents listing, choose Check and Fix Extensions.
3. In the Virtual Host Name field, enter the name of the virtual host.
4. In the Port Number field, enter the name of the port.
5. Click Check.

Recalculating Hyperlinks on the Root Web or a Sub-web

This form recalculates and repairs all internal hyperlinks in the specified FrontPage web on the specified virtual server and port. This also re-includes pages in Include Page components, recalculates other FrontPage components (such as Search Forms and Navigation Bars), reapplies borders to any pages using borders, resets permissions on FrontPage form handler results pages, and recalculates text indices.

1. From your browser, start the HTML Administration Forms by opening fpadmin.htm.
2. In the contents listing, choose Recalculate Links.
3. In the Virtual Host Name field, enter the name of the virtual host.
4. In the Port Number field, enter the name of the port.
5. To recalculate hyperlinks for a sub-web, in the Subweb Name field, enter the name of the sub-web.
6. Click Recalculate.

Enabling Authoring on a Virtual Server

1. From your browser, start the HTML Administration Forms by opening fpadmin.htm.
2. In the contents listing, choose Enable Authoring.
3. In the Virtual Host Name field, enter the name of the virtual host.
4. In the Port Number field, enter the name of the port.
5. Click Enable Authoring.

Disabling Authoring on a Virtual Server

1. From your browser, start the HTML Administration Forms by opening fpadmin.htm.
2. In the contents listing, choose Disable Authoring.
3. In the Virtual Host Name field, enter the name of the virtual host.
4. In the Port Number field, enter the name of the port.
5. Click Disable Authoring.

Changing Permissions for a User

1. From your browser, start the HTML Administration Forms by opening fpadmin.htm.
2. In the contents listing, choose User Permissions.
3. In the Virtual Host Name field, enter the name of the virtual host.
4. In the Port Number field, enter the name of the port.
5. In the Subweb Name field enter the sub-web name.
6. In the Username field, enter the name of the user whose permissions you are adding, removing, or changing.
7. In the Password field, enter the user's password.
8. Select the level of access for the user or, to give the user no access, click Remove this User.
9. Click Change Permissions.

Changing Permissions for a Computer

1. From your browser, start the HTML Administration Forms by opening fpadmin.htm.
2. In the contents listing, choose IP Address Permissions.
3. In the Virtual Host Name field, enter the name of the virtual host.
4. In the Port Number field, enter the name of the port.
5. In the Subweb Name field enter the sub-web name.
6. In the IP Address field, enter the IP address of the computer or set of computers whose permissions you are adding, removing, or changing. You can use the asterisk character "*" as a wildcard, as in 128.109.*.*
7. Select the level of access for the computer or group of computers, or, to remove all restrictions on the IP address or IP address mask, click Remove this mask.
8. Click Change Permissions.

Deleting a Subweb

This is the only way to delete sub-webs on servers of the following types: ncsa, apache, cern. You cannot delete the root web using this command. Instead, use the Uninstall option.

1. From your browser, start the HTML Administration Forms by opening fpadmin.htm.
2. In the contents listing, choose Delete Subweb.
3. In the Virtual Host Name field, enter the name of the virtual host.
4. In the Port Number field, enter the name of the port.
5. In the Subweb Name field, enter the name of the subweb.
6. Click Delete Subweb.

Renaming a Subweb

This is the only way to rename sub-webs on servers of the following types: ncsa, apache, cern.

1. From your browser, start the HTML Administration Forms by opening fpadmin.htm.
2. In the contents listing, choose Rename Subweb.
3. In the Virtual Host Name field, enter the name of the virtual host.
4. In the Port Number field, enter the name of the port.
5. In the Subweb Name field, enter the name of the subweb.
6. In the New Subweb Name field, enter the new name of the subweb.
7. Click Rename Subweb.

Setting a Directory Executable

This is the only way to make a directory executable on servers of the following types: ncsa, apache, cern. To make a directory not executable, use the Set Directory Not Executable command.

1. From your browser, start the HTML Administration Forms by opening fpadmin.htm.
2. In the contents listing, choose Set Directory Executable.
3. In the Virtual Host Name field, enter the name of the virtual host.
4. In the Port Number field, enter the name of the port.
5. In the Subweb Name field, enter the name of the subweb.
6. In the Directory URL field, enter a URL relative to the top-level directory of the FrontPage web.
7. Click Set Directory Executable.

Setting a Directory Not Executable

This is the only way to make a directory not executable on servers of the following types: ncsa, apache, cern. To make a directory executable, use the Set Directory Executable command.

1. From your browser, start the HTML Administration Forms by opening fpadmin.htm.
2. In the contents listing, choose Set Directory Not Executable.
3. In the Virtual Host Name field, enter the name of the virtual host.
4. In the Port Number field, enter the name of the port.
5. In the Subweb Name field, enter the name of the subweb.
6. In the Directory URL field, enter a URL relative to the top-level directory of the FrontPage web.
7. Click Set Directory Not Executable.

The fpremadm Utility

The fpremadm utility is based on the fpsrvadm utility. It supports remote administration of the FrontPage Server Extensions using a client computer via WinInet. It installs, updates, removes, and checks the FrontPage Server Extensions on FrontPage root webs and sub-webs, and performs other administrative FrontPage web operations similarly to fpsrvadm.

The fpremadm.exe utility is only provided for Windows machines. There is no UNIX version of this utility.

In order to use fpremadm you must first enable the HTML Administration Forms, since fpremadm.exe uses the same server-side CGI or ISAPI script as the HTML Administration Forms. The URL used for the HTML Administration Forms will be used in a slightly modified form as the -targetserver argument value to fpremadm.exe.

fpremadm has the same set of operations as fpsrvadm. It includes the following additional options that support remote administration:

The FrontPage Server Administrator Utility

The FrontPage Server Administrator, fpsrvwin.exe, installs, updates, removes, and checks the FrontPage Server Extensions on FrontPage root webs and sub-webs, and performs other administrative FrontPage web operations. It is a Windows-only graphical user interface to the frpsrvadm utility. It can be run even when the Web server is not currently running (although with some server types you may need to have the administration service for the server running in order to use fpsrvwin).

Note: Some FrontPage Server Administrator operations require that you supply the location of the server configuration file. For Netscape servers, the server configuration information is kept in the Windows NT or Windows 95 Registry, in a different area for each port. You must enter the port number in the space provided. For WebSite servers, the server configuration information is kept in the Windows NT or Windows 95 Registry. You only need to enter server-specific information if you are using the multi-homing feature of WebSite, and in this case you must enter the fully qualified domain name for the server host that you are installing.

The FrontPage Server Administrator is implemented as a single dialog box in which you select the operation and set the port number. The dialog box has the following fields:

Select server or port

This field lists the virtual servers and ports on which the FrontPage Server Extensions are installed. Select a virtual server/port number before you perform any operation except Install

Install

Installs the FrontPage Server Extensions on a Web server. You can install on the following Web server types:

• Microsoft Internet Information Server
• Microsoft Personal Web Server
• FrontPage Web Server
• Netscape Communicator
• Netscape Commerce
• Netscape Enterprise
• Netscape Fastrack
• O'Reilly WebSite

Upgrade

Upgrades the FrontPage Server Extensions on the selected virtual server/port. The root web and any sub-webs will be upgraded to the latest version of the Server Extensions on the server machine.

Uninstall

Removes the FrontPage Server Extensions on the selected virtual server/port.

Check and Fix

Checks and fixes the FrontPage Server Extensions installation on the selected virtual server/port.

Checking the server extensions includes replacing missing FrontPage directories and files and making sure all FrontPage executables are present and with the correct permissions. On IIS Web servers and Microsoft Personal Web Servers, you are prompted to tighten security. If you click Yes, FrontPage will optimize security settings on folders and files in your webs. This may change current security settings.

Authoring

Enables or disables authoring on the selected virtual server/port. Click Enabled to enable authoring and Disabled to disable it.

Security

Adds an administrator for the selected virtual server/port. For some server-types you are prompted for a name and password. On other servers, you are just prompted for a name and the system password for the provided name is used.

Creating a New Virtual Server on Windows NT

On IIS2.0 and 3.0 ...

Use the following procedure for creating a new virtual server.

1. You must define the IP Address of the new virtual server using the NT Network control panel. You must reboot after adding an IP address to have it take affect. To avoid rebooting when adding a new virtual server (and thus taking the machine offline for a few minutes), prepare 50 IP addresses in reserve in the registry.
2. IIS security is based on NT machine accounts, so in most cases you will create an NT machine account before you install the FrontPage extensions. You create NT machine accounts with the net.exe utility or the NT User Manager. For help with the net.exe utility, type "net help user" at the MS-DOS command line.
3. Create a content root on the hard drive. Typically this is "C:\InetPub\www.virtualmachinename.com".
4. The content root directory will have an ACL inherited from its parent directory in the file system. Often, the file system has loose permissions, such as granting full control to the EVERYONE account. If this set of permissions is not modified, the EVERYONE account permissions will be preserved during the installation of the FrontPage extensions into this content root, and any user will be able to browse the content area and any user will have the ability to write to the content area (but not via FrontPage). To prevent this, remove these ACLs and set the initial ACL on the content root to a clean baseline which includes any authorized users, the SYSTEM account, and possibly the IUSR_machinename account if the web is to be browsable without authentication.
5. Create a virtual server root with the new IP Address created or allocated in step 1. You can do this using the iisadmin.exe utility or the Windows NT Internet Service Manager application.
6. Install the FrontPage Server Extensions to the root web of the virtual server using the FrontPage Server Administrator, the fpsrvadm utility, or HTML Administration Forms.
7. Optionally add an FTP service to the virtual server using the iisadmin.exe utility or the Windows NT Internet Service Manager.

On IIS4.0 ...

On IIS 4.0, virtual server creation and installation of the FrontPage Server Extensions onto the new virtual root is integrated with the IIS 4.0 administration tools. After creating a new Web site with the New Web Site Wizard, the Server Extensions can be added either with the FrontPage Server Administrator or by using the properties page of the virtual server. Go to the Home Directory Tab, then click on the FrontPage web option, which will automatically install the FrontPage Server Extensions.

On Netscape ...

On Netscape Web servers, use the appropriate administration tool for creating a virtual server, then add the server extensions using the FrontPage Server Administrator tool.

Creating a New Virtual Server on UNIX

1. Create a new UNIX account for the user.
2. Create a content root and configuration file area. For example, /usr/local/www/newuser/content and /usr/local/www/newuser/conf.
3. Create a new virtual server for the new account. Consult your Web server documentation for details.
4. Run the fpsrvadm utility (or use HTML Administration forms) to install the FrontPage Server Extensions on the new virtual server. For example:

fpsrvadm -o install -t servertype -h hostname -u username -pw password -p port -xUser unixuseraccount -xGroup unixgroupaccount

5. Chown the web appropriately. Using the sample command line above, you can do this at the same time you install the FrontPage Server Extensions, using the -xUser and -xGroup options. Otherwise, use the chown option of fpsrvadm. For example:

IIS Security and Permissions Management Strategies

The FrontPage security system uses a combination of the Web server's security system and the web server machine's file system security system. As explained in Security Considerations, in the FrontPage security model, all content within a particular FrontPage web has the same set of permissions for browsing, authoring, and administrative functions.

In some applications easier administration or a finer level of security than the FrontPage web level is required. In some cases, you may want to have permissions settings for authoring or browsing access on a per-directory basis or a per-file basis. Permissions of this type are not directly supported through FrontPage, but by using a combination of FrontPage security management and manual security management it is possible to achieve a finer security granularity. This section contains a range of suggested strategies for fine-grained security and for administering permissions easily.

FrontPage does all security management, but administration of permissions is through the NT User Manager

In this scenario, the FrontPage per-web level of granularity is used, but the FrontPage permissions user-interface in the FrontPage Explorer is not used for security management. The FrontPage permissions user-interface uses the contents of the NT account list to control which users have browse, author, and administrative privileges. However, the FrontPage interface is different from the NT User Manager tools which are used for other Windows NT user administration tasks. To enable administration of FrontPage web permissions via the Windows NT User Manager, use Windows NT groups.

When each FrontPage web is created, create and add a separate Windows NT group to the web for web browsers, authors, and administrators using FrontPage's Permissions command. Once these groups are added using the FrontPage Permissions command, all subsequent control over which users are allowed permissions to the FrontPage web is handled by controlling the membership of the groups using the NT User Manager. IIS and the FrontPage extensions will automatically grant browsing and authoring privileges based on the group membership.

To prevent FrontPage Administrators from altering the FrontPage web's permissions using the FrontPage Permissions command (and thus bypassing the NT groups) reserve FrontPage administrative privileges for Web server machine administrators, and do not grant FrontPage Administrative privileges to content authors. Not granting FrontPage administrative privileges to authors will prevent them from creating new sub-webs. Sub-web creation will have to be done by the Web server machine administrators.

Mix of FrontPage security management and manual management for a few per-directory security settings

If most the web content has uniform security requirements, and only a few of the directories in the web need to have unique security settings, use FrontPage's security management with a few manual changes to the file system to modify security on the exceptional directories. Examples of when this strategy of security management is appropriate are:

• Removing anonymous browse-access from a particular directory, but keeping the rest of the web's content anonymously browsable. In the directory that should not be anonymously browsable, use the Windows Explorer to remove the IUSR_machinename account from the directory and from the directory's content ACLs. As long as the "Everyone has browse access" setting in the FrontPage Permissions dialog box is not changed, you can use the FrontPage Permissions dialog box to add and remove users and groups, and FrontPage will preserve the lack of anonymous access for the directory that was altered.

• If anonymous browsing is off for the entire web, you can modify the ACLS for a particular directory to which you manually gave extra users browse-access. These ACLs will be preserved by FrontPage even if the FrontPage Permissions command is subsequently used.

• You can disallow authoring for a selected directory for a small set of users. In the directory where authoring should not be allowed, remove the users from the directory and directory-content ACLs using the Windows Explorer. The removal of these users will be preserved by FrontPage. This technique is most applicable when anonymous browsing is enabled for the entire web, so that users can always browse the entire web's content but may not be able to author content in a particular directory.

Use of separate sub-webs for finer security granularity

Instead of storing all web content in a single large, hierarchically-organized web, break up the content into a number of sub-webs. Leaf directories in the hierarchical structure become individual sub-webs. By using sub-webs, finer security granularity is automatic since each sub-web maintains separate security settings. An additional benefit of using sub-webs is potentially better performance, because the time required to recalculate hyperlinks is directly proportional to the number and size of the documents stored in a single web. Since each sub-web will store a subset of the documents, the time required for a user to recalculate hyperlinks in that user's content area is less. A disadvantage of this approach is that URLs to access the content no longer reflect an organizational hierarchy, and linking between leaves of the hierarchy is more difficult.

Use a staging server for authoring, and then copy to a production server with manually managed permissions

In this model, all authoring takes place on a staging server that is not used for "production" publishing of the web content, and all permissions are managed using the normal FrontPage Permissions command. When the content is ready to be published it is copied to a production server (either using the FrontPage Publish command or via some other means such as file copying or the Microsoft Content Replication System) and permissions on the production server are set up appropriately outside of the FrontPage Permissions command.

Some advantages of this model are that authoring and works-in-progress are never exposed to users browsing the web, but the disadvantages are that use of some FrontPage Components, such as the default FrontPage form handler, is more difficult because the results files will be on the production server and not on the authoring server. Additionally publishing and fixing up permissions are separate steps that may require special configuration.

Perform all permissions management manually

Permissions can be managed completely outside of the FrontPage Permissions command by directly manipulating file system ACLs for all of the web content. If this approach is used, the following guidelines will help prevent conflicts with FrontPage, however manual management of permissions is not recommended because of the risk of a misconfiguration causing FrontPage to become non-functional or possibly loosening permissions in such a way that leaves the web exposed to unauthorized browsers, authors, or administrators.

• Initially, add a single NT group containing all authors using the FrontPage Permissions command. This correctly sets the authoring permissions on the FrontPage Server Extensions DLLs stored in the web. It is important that the membership of this NT group always contain the set of all authors for the web's content, so that access to the FrontPage DLLs is granted.
• After adding the initial authors group, do not use the FrontPage Permissions command for further permissions management on the web's content. Instead, manage content permissions on a per-file or per-directory basis, using the Windows Explorer or the cacls.exe command to directly modify file system ACLs.
• Do not grant FrontPage administrative privileges to any user. This will prevent a FrontPage user from accessing the FrontPage Permissions command and potentially overwriting the web's customized permissions.
• Selective use of NT groups when modifying file system ACLs will reduce the overhead of adding and removing individual users to all files and directories in a web.
• Do not overwrite the ACLs of the FrontPage _vti_* directories in the root directory of the web. These directories contain configuration data for the entire web and additionally must be accessible to all authors on a given web, and they have permissions settings that are different from the permissions settings on the content stored within the web's root directory. Be particularly careful of the "Replace Permissions on subdirectories" option in the Windows Explorer Permissions dialog box, since use of this option when changing permissions on the root directory of a web will cause the _vti_* directory permissions to be overwritten with the permissions you designate. Doing so may cause some authors of the web to be denied access or possibly may leave the web open for authoring by any user. Use of the cacls.exe command is recommended when manually managing web permissions, since cacls.exe is capable of removing or adding individual users to a given file's ACL, as opposed to overwriting the entire ACL.

IIS 4.0 and the Server Extensions

Administration of the FrontPage Server Extensions with IIS version 4.0 is generally the same as administration with earlier versions of IIS. When using the FrontPage Server Extensions with IIS 4.0, make sure that the FrontPage Server Extensions are not run in a separate memory space, as is optional for IIS 4.0 web sites. Running the FrontPage Server Extensions in a separate memory space will cause the following problems:

• The FrontPage Permissions command will not function correctly.
• Integration of the FrontPage Search Form Component with Microsoft Index Server will not function.
• Authoring performance will be slower.

The iisadmin Utility

The iisadmin utility adds, removes, or modifies virtual servers on Microsoft IIS 2.0 and 3.0 Web servers. This utility is designed to be run from scripts or the command line to automate the maintenance of IIS 2.0 and IIS 3.0 Web servers, which otherwise must be maintained using the graphical Internet Service Manager application.

iisadmin includes the following operations:

The iisadmin options are (see below for a detailed description of which options are valid for each operation):

Add

Adds the virtual root <url> to the machine <targetserver>. If <targetserver> is omitted, it adds the virtual root to the current machine. The content mapped to the server is at <directory>. If <ipaddress> is specified, it is mapped to the virtual root. If <ipaddress> is not specified, all IP addresses registered on <targetserver> are mapped to the virtual root. The <service> can be "www" or "ftp".

The -r, -w, and -e switches set read, write, and execute restrictions on the virtual root.

Delete

Deletes the virtual root <url> mapped to the IP address <ipaddress> from the machine <targetserver>. If <targetserver> is omitted, it deletes the virtual root on the current machine. The <directory> switch is required to ensure that the correct virtual root is deleted.

Edit

Changes the read, write, or execute restrictions on the virtual root <url> on the machine <targetserver>. If <targetserver> is omitted, the change is applied on the current machine. The content mapped to the server is at <directory>. The -r, -w, and -e switches set read, write, and execute restrictions on the virtual root.

Using the FrontPage Configuration File

Some features of the FrontPage 97 Server Extensions can be controlled by setting parameters in the appropriate sections of the FrontPage configuration file.

On Windows, the FrontPage configuration file is frontpg.ini. This file is in the Windows NT folder. The appropriate sections for each virtual server are labeled in the form [Port <IPAddress>:<port>], and global settings are stored in the [FrontPage 3.0] section. The default setting in the software for each of these parameters is 0, unless otherwise noted.

Placing a parameter in the [FrontPage 3.0] section of frontpg.ini will affect all ports and all web servers installed on that server. Placing the parameter in the [Port <IPAddress>:<port>] section will affect only the specified port.

The parameter syntax in frontpg.ini is:

Parameter=value

See frontpg.ini Settings for a full description of this file, with default FrontPage settings.

On UNIX, the general FrontPage configuration file (for all servers) is /usr/local/frontpage/version 3.0/frontpg.cnf. The FrontPage configuration files for each virtual server are also in the /usr/local/frontpage/ directory. They are named we<port>.cnf or <hostname:port>.cnf.

The parameter syntax on UNIX is:

Parameter:value

See UNIX FrontPage Configuration File Settings for a full description of this file, with default FrontPage settings.

The following are some key variables in the FrontPage configuration file:

NoSaveResultsToAbsoluteFile

When set to a non-zero value, prevents the FrontPage default, Registration, and Discussion form handlers from writing to an absolute file path even if the browsing account has the NTFS rights to write to that path. When this is set, the default form handler can only write a file within the web's content area.

NoExecutableCgiUpload

When set to a non-zero value, authors cannot upload files to a directory marked executable, and cannot mark a directory executable. Setting this parameter to a non-zero value completely prevents authors from uploading and executing Active Server Pages (ASP), Internet Database Connector Pages (IDC), PERL Scripts (PL), CGI scripts and ISAPI extensions. To only restrict authors ability to upload and execute CGI scripts and ISAPI extensions use the AllowExecutableScripts configuration parameter, below.

AllowExecutableScripts (IIS Only)

When set to a non-zero value, FrontPage will set the executable bit on files within executable directories. When directories are marked executable all files within the directory will be also marked executable. If authors are permitted to upload into executable directories (because the NoExecutableCgiUpload parameter, above, is zero), then by setting this parameter to a non-zero value, authors will be able to execute newly uploaded CGI scripts and ISAPI extensions because they will be marked executable.

RestrictIISUsersAndGroups (IIS Only)

When set to non-zero, only displays users and groups from a single NT group. If RestrictIISUsersAndGroups is enabled for a given service, the FrontPage Server Extensions look for an NT group named in the following format:

FP_ServiceName[_Subweb]

Where ServiceName is the service's IP address and Port number combination (on a multihosted server) and Subweb is the name of the sub-web. On a single-hosted IIS 2.0 or 3.0 server, the ServiceName portion of the name is the port number, for example "80". To specify a root web's restriction group, omit the _Subweb portion. Some examples are:

FP_157.55.49.66:80_MySubweb
FP_80_MySubweb

If restrictions are enabled on a sub-web but no local group is defined, the FrontPage Server Extensions look for the group of the root web and use it if found. If no appropriately named groups are found, no restriction is placed on permissions.

Logging

When set to a non-zero value, authoring operations are logged to the file _vti_log/author.log in the root web. Each operation is logged with the current time, the remote host, the author's user name, the name of the web, the operation performed, and per-operation data.

Using FTP To Copy a FrontPage Web

FrontPage's Publish command uses HTTP to communicate with the Web server. This command will not transfer the local FrontPage Server Extension files to the target server. When using an FTP application, it is important to transfer only the content files from the originating web server. Do not FTP any _vti _* directories. If these directories or files are transferred, they will overwrite the existing files on the target server. FrontPage Server Extensions should only be installed using the FrontPage Server Administrator utility on the host server or remotely using the HTML Administration Forms.

If you FTP the contents of a FrontPage web to a Web server that does not have the FrontPage Server Extensions, some runtime FrontPage functionality such as form handling and searching will be lost.

Language Settings in FrontPage Webs

Each FrontPage web has two language settings:

• Default Web Language

• Default HTML Encoding

Using FrontPage with Microsoft Index Server

Microsoft Index Server version 1.1 is a content-indexing and search component included with Microsoft Internet Information Server (IIS) 3.0. When the FrontPage 98 Server Extensions are installed with IIS 3.0 and higher, the FrontPage Search Form uses the document index and search component of Index Server. When Index Server is used with IIS virtual servers and FrontPage, there are special considerations described here.

Installing Index Server for Virtual Servers

For information about installing the Index Server, go to http://www.microsoft.com/ntserver/search/docs. (Because the Microsoft Web site is constantly updated, the site address may change without notice. If this occurs, go to the Microsoft home page http://www.microsoft.com .)

For information about setting up the catalog, associating it with a specific virtual server, and configuring Index Server Administration, read "Multiple Catalogs for Multiple Virtual Servers" at http://www.microsoft.com/ntserver/search/docs/cathlp.htm#multiple.

Using the Index Server Administration HTML pages, check the list of virtual roots to be indexed in the catalog and remove any virtual roots you do not want to include in the catalog. Common Roots (virtual roots without specific IP addresses) are indexed in all catalogs by default.

Force the creation of the catalog by browsing to the virtual server and attempting a search.

Index Server Issues

FrontPage can use either of two search engines. The default search engine is the built-in WAIS search engine that is included with the FrontPage Server Extensions. On IIS, if Index Server is installed then FrontPage will use Index Server instead of the WAIS search engine. Web servers other than IIS will always use the built-in WAIS search engine. The pros and cons of each engine are:

If you want to avoid using the FrontPage Search Form, you may design a custom form linked to an .idq file in a directory other than _vti_bin to customize the query.

The catalog can be updated from the Index Server Administration page by performing an incremental directory scan and merging the index. The scan and merge operations are performed automatically as defined by the registry entries ForcedNetPathScanInterval and MasterMergeTime. The default interval for ForcedNetPathScanInterval is 120 minutes and the default for MasterMergeTime is 0:00.

Recalculating FrontPage Webs

The FrontPage Explorer's Tools menu includes a Recalculate Hyperlinks command that FrontPage authors can use to rebuild the internal map of hyperlinks between pages maintained by FrontPage. Recalculate Hyperlinks is a CPU-intensive command because it must reparse every page in the FrontPage web. This command is not normally necessary during FrontPage Web authoring, because the hyperlink map maintained by FrontPage is kept up-to-date in the background as authors create and save pages through the FrontPage client applications. However, if authors move or rename pages in a FrontPage web using a mechanism outside of FrontPage, such as FTP, the Windows Explorer, or UNIX file system commands, you can instruct them to use the Recalculate Hyperlinks command to repair the hyperlink map.

If an author is using a WAIS index, Recalculate Hyperlinks is useful to force the WAIS index to be rebuilt. This may be necessary when words are deleted from pages or when pages are deleted from a FrontPage web.

Recalculate Hyperlinks does the following:

• Reparses all pages in the FrontPage web to rebuild the hyperlink map of the web.
• Forces updating of the WAIS text index and flushes deleted documents from the index.
• Expands FrontPage components such as the Include Page component and the Table of Contents.
• Reapplies FrontPage themes to pages.
• Re-applies shared borders to pages.
• Updates the FrontPage web's meta-information.
• Re-synchronizes Microsoft Visual SourceSafe status.

Setting Up Your E-mail Transport

In Frontpage 98, authors can configure a form to send the form's contents as an e-mail message. In order to send e-mail from the Web server on which the form is stored, you must configure the FrontPage Server Extensions to deliver the e-mail to an e-mail transport.

You configure the FrontPage Server Extensions in the FrontPage Server Extensions configuration file. See UNIX Configuration File Settings or frontpg.ini File Settings.

FrontPage supplies five configuration variables for setting up your e-mail transport: SMTPHost, SendMailCommand, MailSender, MailCharSet, and MailEncoding. You set either SMTPHost or SendmailCommand but not both.

• SMTPHost

SMTPHost=mail.example.microsoft.com
SMTPHost=test:10000
SMTPHost=127.0.0.1

• SendMailCommand

• MailSender

• MailCharSet

• MailEncoding

Microsoft Visual SourceSafe 5.0 Integration

Microsoft Visual SourceSafe is a version control system for team development of software applications, Web sites, publications, and any other projects that benefit from version control. Version control systems track and store changes to each file so that users can view the file's history. A Visual SourceSafe project is a collection of files you store in Visual SourceSafe. Organizing your files in a Visual SourceSafe project is similar to organizing files in directories.

FrontPage 97 and FrontPage 98 webs can be integrated with Microsoft Visual SourceSafe version 5.0. This allows the FrontPage web administrator to synchronize a FrontPage web with a Visual SourceSafe project.

FrontPage/Visual SourceSafe integration is available on all FrontPage-supported Web servers on Microsoft Windows NT Server 4.0 or higher, Microsoft Windows NT Workstation 4.0 or higher, and Microsoft Windows 95. The Microsoft Personal Web Server requires the Windows 95 Distributed Component Object Model (DCOM) update to work with Visual SourceSafe.

To configure Visual SourceSafe and FrontPage for integration, use the following procedures:

• Installing Microsoft Visual SourceSafe for Use with FrontPage
• Configuring Microsoft Visual SourceSafe for Use with FrontPage
• Synchronizing a FrontPage Web with a Visual SourceSafe Project

Once a FrontPage web is synchronized with a Visual SourceSafe project, a FrontPage author or administrator can use the Visual SourceSafe Check Out, Check In, and Undo Check Out commands from the FrontPage Explorer's Edit menu or shortcut menu. All files in the FrontPage web will be stored and tracked in the Visual SourceSafe database.

Many FrontPage web operations cause the FrontPage Server Extensions to move, delete, or check pages in and out of the Visual SourceSafe project that is synchronized with the web. The following table describes FrontPage Server Extensions actions for common FrontPage web operations:

Installing Microsoft Visual SourceSafe for Use with FrontPage

To use Visual SourceSafe Integration with FrontPage you must choose the Enable SourceSafe Integration feature of the Visual SourceSafe setup:

1. Run the Visual SourceSafe installation program setup.exe from the Microsoft Visual SourceSafe 5.0 CD-Rom.
2. Select the Custom installation option.
3. In the Microsoft Visual SourceSafe 5.0 - Custom dialog box, select the Enable SourceSafe Integration option.
4. Select Continue.
   
   Visual SourceSafe will be installed.

Configuring Microsoft Visual SourceSafe for Use with FrontPage

Visual SourceSafe 5.0 includes an Administrator application that you use to set up and configure user accounts for use in Visual SourceSafe 5.0 projects. The Visual SourceSafe Administrator is available on the Start menu as Visual SourceSafe 5.0 Admin.

To enable Visual SourceSafe Integration with FrontPage, you must add the following user accounts using the Visual SourceSafe Administrator:

To add a user account in the Visual SourceSafe Administrator:

1. Run the Visual SourceSafe Administrator.
2. From the Users menu, choose Add User.
3. In the Add User dialog box, type the user name in the User Name field, and leave the Password field blank.
4. Click OK.

Synchronizing a FrontPage Web with a Visual SourceSafe Project

Once you have installed Visual SourceSafe 5.0 and established the user and group accounts that will have permissions to use the Visual SourceSafe project, you must synchronize the Visual SourceSafe project with your FrontPage web.:

1. In the FrontPage Explorer, open the FrontPage web for which you want to create a Visual SourceSafe project.
2. In the Tools menu, select Web Settings.
3. In  the Source Control Project field of the Configuration tab, type "$/" followed by a project name, as in "$/rootweb".
4. Click Apply.

   If the project does not already exist in Visual SourceSafe, it is created and all files in the FrontPage web are checked in. If the project already exists, the FrontPage web and the project are merged. Any file in the FrontPage web that is in an ambiguous state (such as a file that has the same name as a file in the Visual SourceSafe project but that was never in the SourceSafe repository) remains checked out.

5. You are prompted to recalculate the hyperlinks for the FrontPage web. Click Yes.

   After the recalculation, the FrontPage Explorer will reload the web. All items under Visual SourceSafe control will be displayed with a green dot (checked in) or a red checkmark (checked out).

The admin.pl Utility

admin.pl -operation <install> [-port <nnnn>] [-type <servertype>]
    [-web <webname>] [-servconf <server config file>]
    [-multihost <hostname> -username <username> [-password <password>]
    [ -createuser <true|false>] [-groups <grouplist>]
    [-localgroups <localgrouplist>] [-wwwroot <wwwfolder>]
    [-ftproot <ftpfolder>] [-ftprw <rw>]

The admin.pl utility has been created to make it easy for Internet Service Providers to add new FrontPage user accounts quickly. It is a PERL process automation script that creates a new user account on a host Windows NT machine running IIS 2,0 or 3.0, creates a new document root and virtual Web server or FTP server on the host machine, and then installs the FrontPage Server Extensions on the virtual server. You must have the PERL interpreter perl.exe installed on your PC to use admin.pl. admin.pl is installed by default in C:\Program Files\Microsoft FrontPage\version3.0\bin.The admin.pl utility is only provided for Windows machines. There is no UNIX version of this utility.

Admin.pl calls the following NT system and FrontPage utilities:

• The Windows NT net utility, to create new system user accounts and add them to groups
• The FrontPage iisadmin utility, to create virtual World Wide Web or FTP servers
• The FrontPage fpsrvadm utility, to install the FrontPage Server Extensions on the virtual World Wide Web server

You may be prompted by one or more of these utilities for missing arguments.

Admin.pl supports a single operation: Install. When you invoke admin.pl, you supply the Install operation and a set of command line options in the form -option <value>:

Examples:

• To create a World Wide Web virtual server

  This example creates the NT user "adminaccount," creates an IIS virtual World Wide Web server with an IP address 157.54.64.98, and installs a FrontPage 98 root web on this virtual server:

  <Perl Root>\perl.exe admin.pl -operation install -port 80 -username adminaccount -password adminpassword -multihost sample.microsoft.com -createuser true -wwwroot c:\InetPub\wwwroot98

• To create an FTP virtual server

  This example creates the NT user "adminaccount," creates an IIS virtual World Wide Web and a read-only FTP server with an IP address 157.54.64.98, and installs a FrontPage 98 root web on this virtual server:

  <Perl Root>\perl.exe admin.pl -operation install -port 80 -username adminaccount -password adminpassword -multihost sample.microsoft.com -createuser true -wwwroot c:\InetPub\wwwroot98 -ftproot c:\InetPub\wwwroot98\ftp -ftprw r