FrontPage MMC Snap-in
After you have created a virtual server, you can extend it with the FrontPage Server Extensions, which make the virtual server a root web. Before you can extend a virtual server, the server extensions need to have already been installed on the server computer.
If the Web server is not IIS 4.0 or later, click New on the shortcut menu, and then click Web.
You need to extend a virtual server that is, make it a root web before you can create subwebs below it.
A subweb enables you to specify separate administering, authoring, and browsing permission, break web content into logical subdivisions to improve performance, apply a different look to the pages of each subweb, and manage hyperlinks easily.
You can create a subweb only on a root web or subweb or on a folder below the root web or subweb. When you create a subweb, you extend it with the FrontPage Server Extensions at the same time. The system automatically creates a folder for the subweb.
At times, you or the author of a web may decide that it's no longer necessary for a web to include the FrontPage Server Extensions. In that case, you can remove the server extensions from the root web, which removes the server extensions from all subwebs below it.
When you remove the server extensions, any functions in the web that are supported by the FrontPage Server Extensions, such as hit counters and e-mail form handlers, will no longer work. The web content remains. Only the server extensions are removed.
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 that are supported by the FrontPage Server Extensions. The cause of the problem can range from accidentally deleting or renaming essential files to corrupting access control lists (ACLs). To fix many authoring-time problems, you can use the Check Server Extensions command, which:
From time to time, a new version of the FrontPage Server Extensions becomes available. The new version provides enhanced support for web authors and administrators, or fixes to the existing support features, as well as support for all existing functions in FrontPage, such as hit counters. To take advantage of this new support, you must first install the latest version of the server extensions on the server computer, and then upgrade a FrontPage-extended web to this version. You can upgrade the server extensions on root webs only, but upgrading a root web will upgrade all subwebs below it.
The Upgrade Extensions command is only displayed if there is a newer version of the server extensions available. To upgrade the FrontPage Server Extensions for all root webs on a computer, right-click My Computer in the console tree.
A subweb may become out of date, seldom used, or, for whatever reason, no longer useful. For example, a project whose information was published on a company intranet has ended or been reorganized. Or, a subscriber who posted a Web site to an Internet service provider's Web server has discontinued service. In these cases and others, you may need to delete the subweb.
When you delete a subweb, you delete all of its contents, files, folders, and nested subwebs, as well as remove its FrontPage Server Extensions. You cannot undelete a subweb.
If you do not have permission to delete a subweb that is nested below the subweb you are deleting, the nested subweb will not be deleted.
If you decide that a folder contains enough web content (such as Web pages and graphics) to be its own Web site, then you can easily convert that folder into a FrontPage-extended web. In effect, this is one way to create a subweb.
Occasionally, you may decide that a subweb is no longer necessary, but you still want to keep its content. In that case, you can convert a FrontPage-extended subweb into a folder of its parent web. When you convert a subweb into a folder, the FrontPage Server Extensions are removed from the subweb, the subweb is converted into a regular folder of the parent web, and any subwebs nested below the converted subweb are linked to appropriate parent webs.
The subwebs below the converted subweb may acquire different themes and permissions settings. If there are no subwebs below the converted subweb, the pages within the converted subweb may lose some web properties.
As an administrator, you may sometimes need to change the theme, text, graphics, or other content of a web or subweb. If FrontPage is installed on the same server computer as a root web or subweb, then you can open the web directly from the console and change its content or perform other actions in FrontPage. Otherwise, you cannot open a web from the console.
If FrontPage is not installed on the server computer, then the Open With FrontPage command does not appear.
Any changes that are made to the structure of a web can change the links between different parts of that web. For example, if a page is added, renamed, or moved from one folder to another, then the hyperlinks to that page from every other page and document in the web will need to updated, or recalculated, to re-establish logical links. FrontPage automatically recalculates hyperlinks. However, if you want to "force" a recalculation, you can do so.
The role-based permission that you can set and manage on each web for administrators, authors, and Web site visitors by using FrontPage may not always meet your needs. For example, you may want to set permissions on files and folders. You can manually set custom permissions by setting permissions directly on the access control lists (ACLs).
If you use FrontPage to manage permissions, however, it will change any custom permissions you set by resetting the ACLs. To make sure that neither you nor anyone else accidentally overwrites custom permissions, you can disable permissions in FrontPage.
Webs that are being built or that require frequent updating need to be accessible to their authors. But some webs, after they are finished, can contain essential or permanent information that should remain unchanged. Or, you may want to prevent others from modifying a web while you are moving it to a new location or making other changes. To protect the information in a web, you can disable authoring on it, which means that users can neither add to nor change web content.
When a web author wants to include a CGI script or active server page in a Web site, how can you be sure that the author isn't inadvertently uploading a buggy program or worse 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.
Users with permission to modify the content of a web can change text, graphics, links, structure, and so on. To keep track of who made changes to a web and which files were changed, you can log authoring actions in a root web and all of its subwebs. Then the system records the time an author's action was performed, the author's user name, the web name, the remote host, and per-operation data, and stores this information in a log file named _vti_log/Author.log, in the root web. If there were a security breach, you could analyze this log file to determine what authoring activity occurred on the web.
Web information is most vulnerable to interception while it is "in the pipe" —that is, en route from one part of the Web to another. You can substantially harden the pipe against would-be eavesdroppers by requiring the Secure Sockets Layer (SSL) standard for transmitting information between FrontPage, Web browsers, and Web servers.
If you require SSL for authoring, then authors who try to work on the web will get a message saying that they are required to use SSL, which they can choose in FrontPage.
The speed with which a web responds to requests from a FrontPage client depends a lot on the web's size, particularly the number of pages and other files it contains. You can improve a web's response time by "tuning" it. When you tune a web, the FrontPage Server Extensions set aside a certain amount of cache for the web, based on the number of web pages. For example, you can tune a web for less than 100 pages or more than 1,000. You can also customize cache size and full-text search index size.
When a number of people are modifying web content, you can use source control to see who is currently modifying a particular web document, identify any changes, prevent one author's changes from erasing another's, and revert to a previous version of a document, if necessary. To provide source control for a specific web, you can choose the built-in FrontPage source control or use an external source control program that supports FrontPage, such as Microsoft® Visual SourceSafe.
Built-in source control is included with the FrontPage Server Extensions. You can use it to check in and check out a web, and revert to the last saved version of a web. Visual SourceSafe and other source control programs need to be purchased separately and installed on your computer. Typically, external source control programs can do everything the built-in source control does, plus they can track changes and revert to any of several previous versions of a web.
You can use Visual SourceSafe with FrontPage only if the Enable SourceSafe integration option is turned on in Visual SourceSafe. This is a custom installation option that you must select when you install Visual SourceSafe.
Some features require that e-mail be sent to site visitors who browse that web. An example of such a feature is an e-mail form handler. To enable these features to send e-mail, you need to specify the Web server's mail address, a contact address, an SMTP host, a mail-encoding scheme, and a mail character set.
|Last Updated June 1999