Administering an ISP Installation

Common Problems and Resolutions

Problems with permissions can range from a hit counter that does not increment (or an author who cannot open a web) to issues that deal with multiple virtual servers. The following is a list of common problems and resolutions:

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 (usually the IUSR_computername account) accessing the page. Before trying to edit the permissions directly, run the FrontPage command Check Server Extensions. This will reset the permissions on the files in the _private directory.
To run this command
1. On the Windows Taskbar, select Start, point to Programs, Administrative Tools, and Internet Services Manager.
2. Right-click the virtual server that’s having the problem, point to All Tasks, and select 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 Sub-Web. 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 asks for a user name and password.
Make sure that the resulting storage file has Read, Write, and Delete permissions for the user (usually the IUSR_ computername account) submitting the form. 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) ensure that FrontPage has exclusive access to files as necessary. When a Web page is opened, the main lock file, _vti_pvt/service.lck, 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, give Read, Write, Execute, and Delete permissions to all FrontPage users, for the _vti_pvt directory.
Unless the web is restricted, the IUSR_computername account will be a FrontPage user. To resolve this, turn off anonymous browsing in IIS 5.0, and reset the permissions, as described later in this section. When you have finished resetting permissions, 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 earlier in this section. If Basic authentication has been set, the author must have the right to log on locally and might have to enter domainname\username, rather than just username when prompted.
Anyone can open the FrontPage web without being asked for a user name and password.
To solve this problem, see the suggestion for tightening security on a site earlier in this section.
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, suppose you receive one of the following errors for a file called “Test.htm”:
- 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.
Also, examine the NTFS permissions on the file that is giving these error messages, or on 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, adjust them manually. However, if there are several thousand files in the web with incorrect permissions, correcting each one individually 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 is accessed by selecting Permissions from the FrontPage Tools menu. Another method is to run the Fpsrvadm.exe command-line utility and 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.
You are unable to tighten security on a particular file or directory in a FrontPage web.
By default, FrontPage does not allow you to increase security on just one file or directory. You should create a new sub-web 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. Next, manipulate NTFS permissions on this directory, or on a file within it. 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.