Configuring FrontPage Server Extensions

Article
12/09/2009

By Curt Johnson, Web Technologies Writer

Internet Information Services Documentation Team Microsoft Corporation December 15, 1999

This article gives you tips for setting up and configuring Microsoft® FrontPage® 2000 and Microsoft® FrontPage® 2000 Server Extensions to work with Internet Information Server (IIS). Because FrontPage 2000 and FrontPage® 2000 Server Extensions are compatible with Windows NT 4.0 and IIS 4.0, as well as with Windows 2000 and IIS 5.0, you are encouraged to upgrade to FrontPage 2000 if you have not done so already. You can find the download site at the following address:

https://msdn.microsoft.com/library/en-us/dnservext/html/fpovrw.asp

On this Web site, click the FrontPage Server Extensions 2000 link in the left column, labeled FrontPage TOC. In addition to the download site, you'll find tutorials, white papers, and other useful information about FrontPage and FrontPage Server Extensions. You'll also find a link to the FrontPage 2000 Server Extensions Resource Kit:

https://officeupdate.microsoft.com/frontpage/wpp/serk/

If you install only FrontPage and do not install the Server Extensions, you will get most of the features FrontPage offers, except for live-authoring and the following:

Confirmation Field
Discussion Form Handler
Guest Book
Registration Form Handler
Save Results Form Handler
Scheduled Image
Scheduled Include Page
Search Form

For a description of each feature, see the FrontPage documentation.

On the Windows Toolbar, click Start, and click Programs.
For Windows 2000, click Administrative Tools, and then click Internet Services Manager.

For Windows NT 4.0, click Windows NT 4.0 Option Pack, Microsoft Internet Information Server, and then click Internet Service Manager.

To verify that the FrontPage snap-in is installed

In the IIS snap-in, right-click Default Web Site.
For Windows 2000, select All Tasks.

For Windows NT 4.0, select Task.

If the Server Extensions are installed on the Default Web Site, you will see the following FrontPage administration commands:
- Check Server Extensions
- Open With FrontPage
- Recalculate Web
- Remove Server Extensions
If the Server Extensions are not installed, you will see the command Configure Server Extensions.

To install the FrontPage snap-in

In the IIS snap-in, click Console and then click Add/Remove Snap-in.

If the Console menu shows only the Options item, choose Options, and select Always open console file in author mode. Click OK, and exit the IIS snap-in. Reopen the IIS snap-in, and from the Console menu you can now select Add/Remove Snap-in.
Select the Extensions tab, and make sure FrontPage Server Extensions is selected.
If it is not selected, click the FrontPage Server Extensions checkbox, and click OK.

Now the four FrontPage Server Extension commands should be visible.

If you've been running a previous version of the FrontPage Server Extensions, you'll see that the FrontPage snap-in replaces and significantly improves upon the Fpsrvwin utility. The FrontPage snap-in does most of the administrative tasks of Fpsrvwin, Fpsrvadm, and Fpremadm, plus a few more.

The following list shows what the FrontPage snap-in can do:

Extend a virtual server with the FrontPage Server Extensions.
Check and fix the FrontPage Server Extensions on a web.
Upgrade the FrontPage Server Extensions on a web.
Remove the FrontPage Server Extensions from a web.
Delete a subweb (virtual directory under a FrontPage web) that has been extended with the FrontPage Server Extensions.

A FrontPage web is a project containing all the pages, images, and other files that make up a Web site. For a full description of FrontPage webs, see the FrontPage 2000 Server Extensions Resource Kit at the address given at the beginning of this article.
Convert a subweb into a folder, and vice versa.
Recalculate all hyperlinks in a web.
Add an administrator.
Enable or disable authoring on a web.
Tune web performance.
Log authoring operations.
Require SSL for authoring.
Specify that a folder can contain executable scripts or programs.
Enable source control.
Set e-mail options.

Remote and Command-line Administration

There are only two tasks that the FrontPage snap-in can't do:

Administer the FrontPage Server Extensions from a remote computer.
Do command-line scripting.

However, there are other ways to do both of these tasks. For remote administration, you can use the HTML Administration Forms or the Fpremadm utility. For information about configuring the HTML Administration forms, see "Remote Administration" in the FrontPage Server Extensions Resource Kit at this address:

https://www.microsoft.com/downloads/details.aspx?FamilyID=8ad8d9f5-51af-4d17-b1cd-a4be003d6920&DisplayLang=en

For command-line scripting, you can run the Fpsrvadm utility.

The Fpremadm and Fpsrvadm utilities are installed in the following directory by default.

For Windows 2000:

C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\40 Folder

For Windows NT 4.0:

C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\40\bin

For examples and steps for configuring these utilities, see the FrontPage 2000 Server Extensions Resource Kit at the address given at the beginning of this article.

Managing Content

When creating and transferring content created in FrontPage, there are a few tips you should keep in mind. This section gives you pointers on how to successfully move content from one server to another. It also tells you how to configure any content you might want to nest among virtual servers.

Transferring Content

The FrontPage Publish command transfers FrontPage content from one FrontPage-extended web server to another. This command transfers, through HTTP, all of the web-site content to be published. Along with the content, all of the functionality of installed FrontPage components is also transferred.

If, however, you choose another method of publishing or transferring the content, such as FTP, Windows Copy command, or Site Server's Content Deployment, the FrontPage components will not be functional until you run FrontPage Recalculate Web on the production server. You run this command so that the FrontPage Server Extensions on the production server can parse the content and recognize FrontPage components. If the _vti directories from the source server are also copied by FTP, then you may need to remove and reinstall the FrontPage Server Extensions on the destination server.

Because the _vti directories contain server specific information, transferring them from one server to another by copying or replicating content means that you have moved the configuration information from one server to a new server, where the information may not apply. If the configuration information no longer applies, FrontPage will not work. If you encounter this problem, remove and reinstall the Server Extensions on the new server.

Nested Content

Before installing FrontPage Server Extensions, make sure you do not have content nested in overlapping virtual servers. Virtual server directories should not be configured under the root directory for another server.

For example, the following configurations will not work with the FrontPage Server Extensions because they contain nested directories for the virtual servers.

Example 1: Server running on Windows

Default Site C:\Inetpub\wwwroot
Virtual Server 1 C:\Inetpub\wwwroot\virsvr1
Virtual Server 2 C:\Inetpub\wwwroot\virsvr2

Example 2: Server running on UNIX

Default Site /usr/local/www
Virtual Server 1 /usr/local/www/user1
Virtual Server 2 /usr/local/www/user2

If you have configured your virtual servers as in the examples, you must reorganize them for FrontPage Server Extensions to work properly. For examples of non-nested virtual servers, see "Overlapping Virtual Servers" later in this article.

Changing the Root of a Web Site

If you want to change the root of an IIS Web site with FrontPage Server Extensions, follow these steps:

Uninstall the FrontPage Server Extensions from the site where you are changing the root.
Change the document root.
Reinstall the FrontPage Server Extensions.

Note: When you change the document root directory in IIS, you must also reset the permissions on that directory.

FrontPage 2000 now administers permissions at the content root level. Therefore, if you remove and reinstall the FrontPage Server Extensions, your permissions are not lost. When you install the FrontPage Server Extensions, FrontPage assigns the following permissions on the content root:

Type of user	Level of permission assigned
Site visitor	Read, Execute
Author	Read, Execute, Write, Delete
Administrator	Read, Execute, Write, Delete, Change Permissions

Overlapping Virtual Servers

You cannot install FrontPage Server Extensions onto a virtual server that overlaps another virtual server (nested virtual servers). If you try to do this, you'll get the following error message:

Unable to create a web for the url "/" because its root directory,
"c:\Inetpub\wwwroot\web", falls below the root of another web in the
directory "c:\Inetpub\wwwroot".

Overlapping Configurations

The following examples show overlapping configurations:

Example 1

C:\Inetpub\wwwroot\ [Default Web site on IIS]
C:\Inetpub\wwwroot\virtualserver1\C:\Inetpub\wwwroot\virtualserver2\

Example 2

C:\Inetpub\wwwroot\C:\Inetpub\webs\virtualserver1\C:\Inetpub\webs\virtualserver1\virtualserver2\

Example 2 shows virtual servers in different directories with an overlapping configuration. See Example 3 in "Nonoverlapping Configurations" next for an example of this kind of configuration without overlapping.

If you have a configuration like one of these, reconfigure it so that virtual servers do not overlap before installing FrontPage Server Extensions.

Nonoverlapping Configurations

The following examples show configurations on which you can install FrontPage Server Extensions:

Example 1

C:\Inetpub\wwwroot\C:\Inetpub\virtualserver1\C:\Inetpub\virtualserver2\

Example 2

C:\Inetpub\wwwroot\wwwroot2\ [Default Web site remapped to \wwwroot2]
C:\Inetpub\wwwroot\virtualserver1\
C:\Inetpub\wwwroot\virtualserver2\

Example 3

C:\Inetpub\wwwroot
C:\webs\virtualserver1\D:\websites\virtualserver2

Example 3 shows how to configure your virtual servers in different directories without any overlapping.

As long as the virtual servers do not overlap, you can structure them to be anywhere on the server.

Setting Security on an IIS Server

This section tells you how to set up IIS security to best accommodate FrontPage. Because FrontPage Server Extensions has no security of its own, you have to rely on IIS and Windows security. For example, if you don't configure IIS correctly, someone can edit a FrontPage Web site without being challenged for a user name and password.

IIS, in turn, works through Windows NTFS permissions to enforce security. Because FrontPage borrows the security mechanism of the Web server it is extending, you have to configure IIS security in conjunction with NTFS permissions. For details about setting security on a Web site, see the IIS online product documentation.

Resecuring a Site

This section tells you how to restore security if you've determined that unauthorized users are logging on to a Web site as the IUSR_computername. Without examining someone's specific problem and configuration, it's hard to make generalizations. However, the following troubleshooting procedure suggests a way to tighten security on a site:

If your server is configured with nested content or overlapping virtual servers, as described in the "Nested Content" and "Overlapping Virtual Servers" sections earlier in this article, fix those problems first.
If the IUSR_computername account is a member of the Administrators group, remove it from the group. No anonymous user should have administrator privileges.

To learn how to remove a user from the Administrators group, see the Windows 2000 or Windows NT 4.0 documentation.
In FrontPage, on the Tools menu, select Security and then Permissions.
On the Permissions property sheet, click the Group tab.
If the Everyone group is listed, remove it, and click OK.
Reopen the Permissions property sheet, and on the Users tab, select Everyone has browse access.

The IUSR_computername account is a member of the Everyone group, and IUSR_computername should not be a member of any group that has Author access. If Permissions on the Tools menu is grayed out, you are on a file allocation table (FAT) partition. You must store Web content on an NTFS partition to have FrontPage security.

Follow the next procedure if the IUSR_computername account can still open the Web site.

For the root Web site and all its subwebs that use unique permissions, set Only registered users have browse access on the Permissions property sheet.

Similar to a directory hierarchy, a subweb is a site under a main Web site.
To tighten security, open the IIS snap-in, right-click the virtual server, click Tasks, click Check Server Extensions, and select Yes.
Open the FrontPage web. (If you receive an error message, give the IUSR_computername account Read, Write, and Delete permissions to the _vti_pvt directory of the web in question).
Set the site back to Everyone has browse access. Exit the FrontPage Explorer, and retest the security of the web in FrontPage.
If you've tried each of the previous steps, but still have no security, or if you get unexpected results when managing content with FrontPage, reset NTFS permissions back to the default, and let FrontPage retake control.

You can do this step for a single subweb if the problem is localized, or for an entire virtual server if necessary.

See also "Resetting Permissions in a Subweb" and "Resetting Permissions on a Virtual Server" later in this article.

Setting Permissions

As mentioned earlier, FrontPage borrows security from NTFS permissions and IIS security. Unless you understand how the FrontPage security model works, it's best to let FrontPage manage Web permissions for you. For details on the security model and how FrontPage uses Windows and IIS security features, see the "Security on Windows NT" in the FrontPage Server Extensions Resource Kit at this address:

https://www.microsoft.com/downloads/details.aspx?FamilyID=8ad8d9f5-51af-4d17-b1cd-a4be003d6920&DisplayLang=en

This section gives several examples of improperly set permissions and tells you how to correct them.

For a detailed description of the FrontPage security model on IIS and guidelines for the minimum permissions needed, see the "Security on Windows NT" section of the FrontPage 2000 Server Extensions Resource Kit at the address given at the beginning of this article.

Common Problems and Resolutions

Problems with permissions can range from a one-hit counter that does not increment (or one author that cannot open a web) to several issues across multiple virtual servers. The following list tells you how to resolve the most common problems:

The hit counter on a Web page shows up as a broken image or is stuck at 1.

Make sure the file _private/Filename.htm.cnt has Read, Write, and Delete permissions for the user accessing the page (usually the IUSR_computername account). Before trying to edit the permissions directly, run the FrontPage command Check Server Extensions, which will reset the permissions on the files in the _private directory.

To run this command:
1. On the Windows Taskbar select Start, and click Programs.
2. For Windows 2000, click Administrative Tools, and then click Internet Services Manager.
  
  For Windows NT 4.0, click Windows NT 4.0 Option Pack, Microsoft Internet Information Server, and then click Internet Service Manager.
3. In the IIS snap-in, right-click the virtual server that's having the problem, point to All Tasks (Task IIS 4.0), and click Check Server Extensions.
If the command fails to resolve the problem, then IUSR_computername, Network, Interactive, or Everyone is more than likely listed on the Permissions property sheet, which you can access from the Tools menu in FrontPage. If that is the case, follow the steps in "Resetting Permissions in a Subweb" later in this article. The same solution applies to problems with forms.
When a user tries to submit a form, FrontPage returns an error message in the browser or challenges for a user name and password.

Make sure that the resulting storage file has Read, Write, and Delete permissions for the user submitting the form (usually the IUSR_ computername account). You can find the name of this file by looking in the source HTML of the form, or by checking the Form properties in the FrontPage Editor.
The Web root is busy or cannot open Service.lck for Read/Write permissions.

Lock files (*.lck) make sure that FrontPage has exclusive access to files as necessary. The main lock file is _vti_pvt/service.lck. When opening a Web page, this file must be accessible. If there are insufficient permissions for the IUSR_computername account or if the file is corrupt, an error message is returned.

To correct this problem, for the _vti_pvt directory give Read, Write, Execute, and Delete permissions to all FrontPage users. Unless the web is a restricted one, the IUSR_computername account will be a FrontPage user. The easiest way to fix this problem is to turn off anonymous browsing in IIS, and follow the steps in "Resetting Permissions in a Subweb" later in this article. When you have finished resetting permissions, be sure to turn anonymous browsing back on.
An author cannot open the web to add or edit content, but a Windows administrator can.

Make sure that the author has been added to the FrontPage web as an author and that the content is correctly structured, as described in the section "Managing Content," earlier in this article. If Basic authentication has been set, the author must have the right to log on locally and may have to enter domainname\username rather than just username when prompted. For information about how to grant a user Log on locally rights, see "Granting Log On Locally Rights" later in this article.
Anyone can open the FrontPage web without being challenged for a user name and password.

To solve this problem, see "Setting Security on an IIS Server" earlier in this article.

When trying to open, rename, or save a file to a web in the FrontPage Explorer or Editor, one of three errors is returned. For example, say the file is called Test.htm, and suppose you receive one of the following errors:
- Cannot open file "Test.htm"
- Cannot rename file "Test.htm"
- Cannot save file "Test.htm"
To eliminate these errors, if you've selected integrated Windows authentication, make sure you're not authoring as the anonymous user. For more information on how to check you are not authoring as the anonymous user, see "Resecuring a Site" earlier in this article.

Also, examine the NTFS permissions on the file giving these error messages, or the parent directory. The user you are authenticating to the FrontPage web must have sufficient permissions on the file, such as Read, Write, and Delete. If the permissions are incorrect, correct them manually. If there are several thousand files in the web with incorrect permissions, correcting each one will take too long. A more efficient alternative is to remove the author in question from FrontPage permissions. You can change permissions on the Permissions property page, which you can access by selecting Permissions from the FrontPage Tools menu, or you can run the Fpsrvadm.exe command-line utility. Then reinstate the author with FrontPage permissions.

Note: If you have to change permissions on thousands of files, security changes may take several minutes to propagate.

If you continue to have any problems listed in this section, see step 4 in the "Resecuring a Site" section, earlier in this article.
You cannot tighten security on only one file or directory in a FrontPage web.

By default FrontPage does not support increasing security on only one file or directory. The best way to make this change is to create a new subweb with unique permissions and then set the desired permissions through FrontPage.

Alternatively, you can target one file or directory by changing NTFS permissions. First, create a virtual directory that is physically outside the FrontPage content area. You can then manipulate NTFS permissions on this directory or on a file in the directory. There is no danger of FrontPage overwriting NTFS permissions. The only drawback to this method is that FrontPage will not recognize that virtual directory and therefore will not be able to manage it.

Granting Log On Locally Rights

This section tells you how to grant users rights to Log on locally or how to verify that a user has Log on locally rights.

To grant Log on locally rights in Windows 2000

On the Windows 2000 Desktop, right-click the My Computer icon.
Select Manage.
In the left pane of the Computer Management tool, double-click System Tools.
Double-click Group Policy, then Computer Configuration, then Windows Settings, Security Settings, Local Policies, and then User Rights Assignments. Figure 1 shows where in the Windows 2000 Computer Management tool to set user rights.

Figure 1: Computer Management, User Rights
In the right-hand pane of the Computer Management tool, double click Log on locally.

On the Log on locally screen, you'll see a list of users for that computer and a box to the right of the user name, under the heading Local Policy. Figure 2 shows how to set the Log on locally permission.

Figure 2: Log on locally dialog box
Select the Local Policy box for the user or verify that the box has been selected.

To grant Log on locally rights in Windows NT 4.0

On the Windows Toolbar, click Start, and click Programs.
Click Administrative Tools, and then click User Manager for Domains.
On the Policies menu, click User Rights.
In the Grant to box, select the user you want to grant Log on locally rights to.

If the user's name doesn't appear in the Grant to box, you must add it. Click the Add button, click Show Users, and select the user from the list in the Names box. Click Add and then OK.
In the Right box, select Log on locally.
Click OK.

Resetting Permissions in a Subweb

The easiest way to fix permissions problems in FrontPage is through the client. Two procedures follow to correct these problems. The first tells you what to do if a user cannot access a web, even though the user has permission. The second tells you how to fix authoring problems with the Check Server Extensions command.

Cannot Access a Web Site

These steps are for a user who cannot access a web even though FrontPage says that the user has permission. If this is not relevant to your situation, skip steps 3 and 8.

If you get errors relating to the Service.lck file, turn off anonymous browsing on the Web server.
Log on as an administrator, and in FrontPageopen the web that is having the problem.
Remove the user account that receives the error, and click Apply.
If you see the IUSR_computername account listed under the Users tab, remove it.
Switch to the Groups tab. If Network, Interactive, or Everyone is listed, remove them as well, and click Apply.
Back under the Users tab, set browse access to Only registered users have browse access, and click Apply.
After the settings have been applied, reset browse access back to Everyone has browse access.
Add the problem account back in with author access, and click Apply.
If you had to turn off anonymous browsing, turn it back on.

If the problem involves not being able to write to a Web site, try the next procedure.

Cannot Perform Authoring Tasks

Occasionally, an author of a web might not be able to upload web content, modify the web directly on the server computer, or perform other authoring functions supported by FrontPage Server Extensions. The cause of the problem can range from accidentally deleting or renaming essential files to corrupting Windows 2000 DACLs (or Windows NT 4.0 ACLs). The Check Server Extensions command can fix many authoring problems by doing the following:

Checks that files have Read access permission.
Checks that the files Service.cnf and Service.lck have Read and Write access.
Updates the files Postinfo.html and _vti_inf.htm.
Verifies that the files _vti_pvt, _vti_log, and _vti_bin are installed and that _vti_bin is executable.
Determines whether virtual server roots or metabase settings are correct and up-to-date.
Checks that the IUSR_computername account doesn't have Write access.
Warns you if you are running on a FAT file system, which means that you cannot supply any Web security whatsoever (if you're running IIS).

To check server extensions on a web

In the console tree, right-click the web for which you want to check and fix the server extensions.

The selected web will be checked and fixed, as well as all subwebs below it.
Click Tasks on the shortcut menu, and then click Check Server Extensions.

The Check Web window displays a status log for each web that is checked.
If you are asked to tighten security as much as possible, select Yes.

Resetting Permissions on a Virtual Server

This section contains two sets of procedures for fixing permissions on an entire server without losing any custom permissions that have been set in each subweb.

Before you work through these procedures, make sure that there are no custom script files in the directory structure you are working on. Otherwise, you may need to reset the permissions on these files after you have finished.

Note: While you work through these steps, users will get a password prompt when trying to browse webs until permissions have been reset.

One Virtual Server

The following procedure shows how to reset permissions for a configuration of a single virtual server with only a few subwebs. If you have several subwebs, work through the procedure in the next section, "Multiple Virtual Servers."

Open a subweb in FrontPage.
If you find the IUSR_computername account in the Users tab, remove it. Also remove the Network, Interactive, and Everyone groups if they are listed under the Groups tab.
Click Apply.
Set browse access to Only registered users have browse access, and click Apply.
Verify that none of the users or groups you just removed has reappeared under the Users or Groups tabs. If they have reappeared, remove them.
Repeat the previous steps for each subweb on the virtual server.

Save the root web for last, mainly to avoid password random prompts.
From the IIS snap-in, right-click the virtual server, and select All Tasks (Task in IIS 4.0), and click Check Server Extensions.
Select Yes when you see the prompt: Do you want to tighten security as much as possible?
Open the root web with FrontPage.

If you get an error message such as Cannot open service.lck for writing, turn off anonymous browsing on the Web server. (You can turn it back on as soon as you have completed step 9.)
From the Tools menu in FrontPage, select Permissions, and on the Permissions property sheet, select Everyone has browse access, and click Apply.
Repeat steps 9 and 10 for each subweb.

Multiple Virtual Servers

The following procedure shows how to reset permissions for multiple virtual servers, each with multiple subwebs that have unique permissions. First, you have to restrict browser access and then reset permissions on each virtual server.

To restrict browser access

From the document root (containing the virtual servers on which you need to reset permissions), open a command prompt and type the following command:

For example, for the Default Web site (found in the C:\Inetpub\Wwwroot directory by default), open a command prompt and change to the C:\Inetpub directory, and run the following command:

cacls wwwroot /T /E /R iusr_computername network interactive everyone

The Wwwroot directory is just an example. Substitute your content directory's path in the preceding command.

From the IIS snap-in, right-click the virtual server on which you want to change permissions, select All Tasks (Task in IIS 4.0), and click Check Server Extensions.
Select Yes when you see the prompt: Do you want to tighten security as much as possible?

At this point, Browse access will be restricted.

Once you are in the site with FrontPage, turn Anonymous access back on, by following these steps:

Open the root web with FrontPage.
From the Tools menu in FrontPage, click Security and then Permissions.
On the Users tab of the Permissions property sheet, select Everyone has browse access, and click Apply.
Repeat the previous step for each subweb that was set with unique permissions.

How These Solutions Work

The majority of the problems that FrontPage encounters are caused by changes to NTFS permissions. Normally IUSR_computername is granted Read and Execute permission from the top of the document tree. When IIS finds IUSR_computername can execute Admin.dll and Author.dll, it never prompts FrontPage for a password. From this point, one of two things happen:

Everything appears to work, except that the anonymous user creates all documents. This occurs only if IUSR_computername was given Change or Full Control permission in the document tree.
When you try to save a file, FrontPage returns an error message saying it cannot write to a given file, or FrontPage corrupts the document (caused by problems in the _borders and _derived directories).

The previous solutions remove problem accounts either through FrontPage or the Cacls command. Using the Windows Explorer to reset permissions replaces all other permissions with the new ones. Once Cacls or FrontPage have done their work, the FrontPage Server Administrator verifies the results.

After making the appropriate change, reactivate anonymous browsing through the FrontPage client, so that FrontPage will put IUSR_computername only where it has to be, and with the tightest possible security.

Configuring E-mail

This section offers solutions to two common problems that can crop up when you try to submit a form through FrontPage. These problems are illustrated in the following scenarios:

Scenario 1

Errors appear in a client's browser when a form is sent through e-mail.

Scenario 2

After filling out a form, the client receives a confirmation, but the form isn't sent.

Scenario 1

An ISP's customer publishes a form on the Web server, and the form is designed to send e-mail results. However, when someone tries to submit the form, a FrontPage error appears in the Web browser and no e-mail is sent. Or when someone is authoring live on the server and attempts to e-mail a form, the client receives the following error message instead of the form:

The FrontPage Server Extensions have not been configured to send e-mail.
Please direct your system administrator or Internet Service Provider to
follow the instructions at "Setting Up Your E-mail Transport" in the \SERK\enu\admin.htm file on the FrontPage CD-ROM.
Would you like to remove the e-mail recipient? Yes/No

Solution

To keep your clients from receiving an error message, make sure you have configured mail settings in the IIS snap-in.

Some features, such as an e-mail form handler, require e-mail to be sent to visitors who browse a web. To allow these features to send e-mail, you need to specify the following in the IIS snap-in:

Web server's mail address
Contact address
SMTP host
Mail-encoding scheme
Mail character set

To configure mail settings

In the IIS snap-in console tree, right-click the Web site for which you want to set e-mail options.
Click Properties on the shortcut menu, and then click the Server Extensions tab.
In the Options box, click Settings.
Enter the settings you want.

The available settings are:

Web Server's mail address

Type the e-mail address that you want to appear in the From line of any e-mail messages sent by FrontPage components. (For example, the form results component sends e-mail when someone fills out a form on a Web page. This component sends the information on the form to the author.) This setting is equivalent to the MailSender setting in Microsoft® FrontPage® 98, but is now stored in the registry instead of the Frontpg.ini file.
Contact address

Type the e-mail address that users should write to if they have problems. The address you enter will appear on error messages that are displayed for some problems encountered by FrontPage users.
Mail server

Type the name of the SMTP server that will deliver any mail sent from the web, or accept the default value, port 25. When a user submits a form whose results are to be sent through e-mail, the FrontPage Server Extensions connect to the SMTP server to deliver the mail. By default FrontPage assumes the server is listening on port 25 (the standard for SMTP), but you can override this port by appending ":nn" to the name and IP address. (The nn is the number of the new port.) This setting is equivalent to the SMTPHOST setting in FrontPage 98, but is now stored in the registry instead of the Frontpg.ini file.

For example:

mail.example.microsoft.com (Standard mail server name)

- 127.0.0.1 (Mail server's IP address)

mail.example.microsoft.com:31 (Standard Mail server name on different port)

- 127.0.0.1:31 (Mail server's IP address on different port)
Mail encoding

Select the mail-encoding scheme you want, or accept the default. This scheme encodes the contents of your mail messages in binary format. You should select default encoding to let FrontPage detect the correct encoding for you. In most cases, FrontPage will detect the correct encoding. However, if you send mail to a person with an incompatible encoding, then change your encoding to one that is compatible.
Character set

Select the appropriate character set to be used in e-mail messages, or accept the default. Each character set is the alphabet of a different language. The same byte maps to a different character in each table (and so in each language). When you accept the default setting, FrontPage automatically detects the character set for you.

Scenario 2

The second common problem can occur when a form appears to be sent and the person filling out the form receives a confirmation page, but the form never reaches the target address.

Solution

A filter at the local mail server or at a remote mail server is probably deleting junk mail. Many mail servers check that the From address of e-mail they process is valid. By default the FrontPage server extensions send e-mail indicating that the user has submitted the form. So, on an IIS server the e-mail may appear to come from IUSR@webserver, or on a Netscape Server as system@webserver. You can solve this problem by verifying that the mail server accepts the Web server's mail address specified in the IIS snap-in. If the mail server is not accepting the Web server's mail address, change this setting to a different account—one that the mail server is configured to accept. See "Scenario 1" for instructions about configuring this setting.

If mail still isn't being received, check to see that mail sent from another e-mail client on the same server is being received. If it is not being received, you may have mail server problems. If this is the case, and there are additional mail servers available, configure the Server Extensions to use a different mail server.

Uploading Executable Scripts or Programs

When a web author wants to include a CGI or an ASP script in a web, you want to make sure that the author isn't inadvertently uploading a buggy program or a virus onto your Web server. You can avoid the risks associated with bugs and viruses by preventing an author from uploading scripts and programs to any folder that is part of a web. To do this:

In the IIS snap-in, right-click the root web for which you want to make folders executable.
On the menu, click Properties, and then click the Server Extensions tab.
To allow the folder to contain executable scripts or programs, make sure that the Allow authors to upload executables check box is selected. To prevent the folder from containing executable scripts or programs, make sure that the Allow authors to upload executables check box is cleared.

Because the default setting prevents authors from uploading executables, you may find that your authors get an error message similar to the following:

Server error: The folder "/Cgi-bin" is marked executable. You are not
allowed to put files into an executable folder on this server.

Note: In this example error message, the Cgi-bin directory can be any folder with Executable permission on the server.

This error will occur if the author tries to upload files from an executable folder from a client computer to an executable folder on the server. When this happens, you could ask the author to let you test the files before publishing them. If you are confident the author is publishing safe executables, follow the steps in this section to allow the author to upload files into executable folders on the server.

Configuring FrontPage Server Extensions

On This Page

Introducing the FrontPage Snap-in

Remote and Command-line Administration

Additional resources