 | ||
|
| ||
| ||
|
| ||
Microsoft Corporation
Updated October 1998
Contents
Introduction
FrontPage Server Extensions
Administration Features
Authoring Features
Browse-Time Features
Planning Considerations for Using Server Extensions
Hardware Requirements
Supported Software Configurations
Win32 Environments
UNIX Environments
Sample Web Sites
Installing/Deploying FrontPage 2000 Server Extensions
Installing Server Extensions
Setting Up Your Web with the FrontPage 2000 Server Extensions
Setting up Security
Maintaining a Web with FrontPage Server Extensions
Management
Remote Administration
Batch File Scripting
Scaling Webs
Reports
Auto Features
Conclusion
Microsoft® FrontPage® Web site creation and management tool provides you with everything you need to create and manage effective Web sites. Not only can you use FrontPage to create exactly the site you want, but FrontPage also makes updating and managing your site easier than before.
Using FrontPage and the FrontPage Server Extensions, you can quickly develop and maintain a corporate intranet, extranet, and public Web site. This white paper briefly describes the functionality enabled by the FrontPage Server Extensions, and then provides information about how system administrators can plan, deploy, and manage FrontPage-based Web sites using the FrontPage Server Extensions.
This white paper also details new administrative features, such as nested sub-Webs and MMC-based administration, which make it easier to create, publish, and manage FrontPage-based webs. These features also allow administrators to host a large number of Web sites on both Windows NT® and UNIX platforms without seriously impacting performance.
Specific details on implementing the FrontPage Server Extensions can be found in the Microsoft FrontPage Server Extensions Resource Kit, which is available on the Web at http://www.microsoft.com/frontpage/.
The FrontPage Server Extensions are a set of programs on a Web server that let you administer, author, and browse a FrontPage-based Web--a structure containing all of the pages, images, subdirectories, and other files that make up a Web site.
The Server Extensions use standard Web server extensions interfaces, such as CGI and ISAPI, and work with virtually all existing Web servers. This design allows the FrontPage Server Extensions to be ported easily to all popular hardware and software platforms for cross-platform, Web-server compatibility.
Communication between the FrontPage-based client and a Web server running the Server Extensions uses HTTP, the same protocol that Web browsers use to interact with a Web server. This communication makes it easier to create, publish and manage your Web and add a range of new functions to your Web, including the following administering, authoring, and browsing capabilities.
Using the FrontPage Server Extensions, a Web administrator can administer a FrontPage-extended Web directly from the FrontPage-based client computer without being a machine administrator of the server computer. Now the Web administrator can set user permissions, create and configure new FrontPage-extended Webs and sub-Webs, and even set source control options for the Web-- without the special knowledge and access privileges needed by a Windows NT or UNIX server administrator.
The FrontPage Server Extensions allow you to perform the following administrative functions remotely.
Microsoft FrontPage is a client/server Web-authoring tool. The FrontPage Server Extensions allow a user to save files directly to a remote server, and perform certain authoring tasks directly on the server.
For example, using the Server Extensions, files can be renamed on the server quickly and efficiently. When you rename a file on a Web server, you also have to update any pages that link to the renamed file. Without the Server Extensions, this is possible, but very expensive because every updated file needs to be uploaded to the server. Using the Server Extensions, the FrontPage Editor sends a single command to a server that then makes all necessary updates to links on other pages.
The Server Extensions also allow an entire team to work on the same FrontPage-based Web simultaneously by providing multiuser access and version control features. With these multiuser features, a team can maintain its Web on a central server. Team members can all access the Web files directly from their personal computers, creating, editing, and arranging files from a single content source. The Server Extensions version control feature ensures that no other user accidentally overwrites any changes.
The FrontPage Server Extensions allow you to perform the following authoring functions remotely.
The browse-time features of the FrontPage Server Extensions are used when a user views a page in a FrontPage-extended Web using a Web browser. Browse-time support is implemented in the FrontPage Server Extensions as FrontPage components.
A FrontPage component is an object that is inserted in an HTML page using FrontPage. It has a persistent state that is encoded in HTML comments. FrontPage components can be run at authoring time (while using FrontPage), or at browse time (while using a Web browser). For example, the Include component is an authoring-time component that inserts the contents of one page into another.
When a user browses an HTML page containing a browse-time FrontPage component, the Server Extensions do whatever processing is required and then generate a new HTML page to display the results of the operation. An HTML page with no browse-time FrontPage components does not use the Server Extensions when a user browses to the page. Instead, the standard Web server page-retrieval process occurs.
The FrontPage Server Extensions provide the following browse-time features.
When you are planning the implementation of a FrontPage-extended Web using the FrontPage Server Extensions, you need to take several factors into consideration, including what hardware is required, what Web server to use as your platform, and how you plan to use your Web. This section discusses the hardware required and the server configurations supported by the FrontPage Server Extensions, and gives some examples of Web sites that you might create using the Server Extensions.
When you deploy FrontPage 2000 with Server Extensions, your hardware requirements will largely depend on your specific situation. As a general rule, expect your hardware requirements to be the same as the requirements for running your Web server-- whether you are hosting a large Internet site, a large number of Internet home pages, an intranet workgroup server, or a centrally managed intranet server.
The FrontPage 2000 Server Extensions support a wide variety of server/platform configurations, making it possible for you to take advantage of the functionality of the Server Extensions regardless of the Web server you are using.
The following table illustrates the various possible software configurations for running FrontPage Server Extensions in a Win32 environment.
| Platform | Operating system | Web servers |
| Intel x86 | Windows NT Server
Windows NT Workstation
Windows 95 |
Internet Information Server 3.0, 4.0
Internet Information Services 5.0 Microsoft Peer Web Services (on Windows NT Workstation) Netscape Enterprise 3.0 Netscape FastTrack 2.0 O'Reilly WebSite Microsoft Personal Web Server (on Windows 95) FrontPage 97 Personal Web Server |
| Alpha | Windows NT Server 4.0 or higher
Windows NT Workstation 4.0 or higher |
Internet Information Server 3.0, 4.0
Internet Information Services 5.0 Microsoft Peer Web Services (on Windows NT Workstation) |
The following table illustrates the various possible software configurations for running FrontPage Server Extensions in a UNIX environment.
| Platform | Operating System | Web Servers |
| Alpha | Digital UNIX 3.2c, 4.0 | Apache 1.2.4, 1.2.5, 1.3
NCSA 1.5.2 Netscape Enterprise Server 3.0 Netscape FastTrack 2.0 Stronghold 1.3 |
| Intel x86 | BSD/OS 2.1, 3.0 | (Same as above) |
| Intel x86 | Linux 3.0.3
(Red Hat Software) |
(Same as above) |
| Intel x86 | SCO OpenServer Release 5 | (Same as above) |
| Intel x86 | Solaris 2.6 | Apache 1.3.3
NCSA 1.5.2 Stronghold 1.3 |
| PA-RISC | HP/UX 9.03, 10.01 | (Same as above) |
| RS6000 | AIX 3.2.5, 4.x | (Same as above) |
| Silicon Graphics | IRIX 5.3. 6.2 | (Same as above) |
| SPARC | Solaris 2.4, 2.5 | (Same as above) |
How you deploy FrontPage and the Server Extensions to create your Web site depends significantly on your authoring and publishing models. Here are some examples of different FrontPage Web site configurations designed to meet the needs of different authoring and publishing models.
Workgroup site -- a small internal site providing information to a single workgroupIf this site has a single author, the most efficient configuration is a FrontPage-based Web hosted locally on a Personal Web Server (PWS) on the author's personal computer. The author creates and edits the Web from the desktop with Server Extensions installed on the PWS.
If this site has several authors, the best configuration is a FrontPage-based Web hosted on a central server with Server Extensions installed. All of the authors create and edit files directly on the server, with the Server Extensions' source-control feature helping to ensure that two authors do not work on the same file at the same time.
Intranet site -- a large internal site providing information to a variety of people within a medium- to large-sized organizationA site of this size most likely has a team of authors, in which case, the best configuration is a FrontPage-based Web with several sub-Webs, hosted on a central server. The site may possibly be authored first on a staging server with Server Extensions installed. The authors all work from files on the central server. Depending on the number of authors, they may choose to install the Visual SourceSafe version control system for additional source-control features, such as version annotation and the ability to merge versions.
Small Internet site-- an external site with relatively few pages, hosted remotely by an ISPIf the site has a single author, the best configuration is a FrontPage-based Web created and edited locally on a PWS, then posted through HTTP to the remote server. To take full advantage of features like incremental publishing and run-time dynamic content, both the PWS and the remote host server must have the Server Extensions installed.
If the site has several authors, one possible configuration is a FrontPage-based Web hosted locally, either on a PWS or on a central server. All authors write and edit the files that reside in this central location. A single administrator would then post all of the files to the remote server. In this scenario, both the local server and the remote server must have the Server Extensions installed.
If the several site authors do not all have access to the same local network, another possible configuration is a FrontPage-based Web hosted on the remote server with Server Extensions installed. In this scenario, each author pulls files down and saves them back directly to the remote server over the Internet, using HTTP. This configuration is particularly useful for "virtual workgroups."
Large Internet site -- a large, external point-of-presence Web site with several authors and heavy user trafficIn this scenario, an ideal configuration is a FrontPage-based Web hosted on a central server with the Server Extensions installed. Because it is an external site, administrators most likely use a staging server. Authors create, write, and save files to the central server, with source control provided either by FrontPage itself or by Microsoft Visual SourceSafe™.
After you decide on a Web server and platform and install and configure the necessary hardware and software, your next step in setting up a FrontPage-extended Web is to install and configure FrontPage and the Server Extensions. This section describes the processes involved in installing the Server Extensions, creating the structure of your FrontPage Web, and configuring security for your FrontPage Web.
Note This section is not meant to serve as an installation and deployment guide. The purpose of this section is to give the reader an idea of the process and resources necessary to install and deploy the FrontPage 2000 Server Extensions. For a full guide to installing and deploying the FrontPage Server Extensions, visit the Web at http://www.microsoft.com/frontpage/.
You can install the FrontPage 2000 Server Extensions either on a client computer to support a local PWS, on an Internet server to support hosting FrontPage-based Webs on the Internet, or on an intranet.
There are two steps to installing the FrontPage Server Extensions. First, run the installation program to first copy the Server Extensions to a single FrontPage directory on the host computer's hard drive. Second, setup then installs the Server Extensions stub DLLs or stub CGI executables on the root Web of each virtual server on the host computer, and, if sub-Webs exist on the server, on each sub-Web. During Server Extension installation, you can specify on which virtual servers you wish install the Server Extensions.
After setup copies the Server Extensions to a host computer's hard drive, the extensions must be added to each new FrontPage-based Web that is created. On some platforms this is initiated automatically by the FrontPage client setup program. On other platforms, it must be done as a separate administrative task.
When you install the FrontPage Server Extensions for a Windows platform, setup installs the following components:
Please note that you must be a Windows NT or UNIX systems administrator to install the FrontPage Server Extensions. For complete installation instructions, see the FrontPage 2000 Sever Extensions Resource Kit.
Once you have installed FrontPage and the Server Extensions, you can use the Server Extensions to set up and configure your FrontPage Web. Each FrontPage-based Web begins with a root Web, the top-level content directory of a Web server, or in a multi-hosting environment of a virtual Web server. A root Web can have many levels of subdirectories, which contain the Web's content. There can be only one root Web for each Web Server or virtual Web server. At some point, the number of subdirectories under a root Web may begin to affect performance. To optimize scalability, FrontPage Server Extensions allow you to extend a root Web either by creating sub-Webs under the root Web or by creating a second root Web as a virtual server.
A sub-Web is a complete FrontPage-extended Web that exists as a subdirectory of the root Web, or of another sub-Web. Sub-Webs allow an administrator to break up the contents of a FrontPage-based Web, and assign different areas to different owners and groups. Each sub-Web can have many levels of subdirectories.
A virtual server allows your single Web server to host multiple Web sites, each of which appear to a browser as its own Web server. Through the use of virtual servers, you can use a single computer to host several individual FrontPage root Webs, each with unique content and access permissions.
Sub-Webs are the FrontPage mechanism for breaking up a Web site so that different areas can be owned and maintained by different people or workgroups. Often corporate Internets and intranets are made up of subsections, each controlled by a different groups within the organization. Using sub-Webs, a FrontPage administrator can set up a structure within a FrontPage-extended that allows each group to control access to its own subsection.
In earlier versions of FrontPage, sub-Webs could only exist directly under a Web's root, but in the FrontPage 2000 web site creation and management tool, you can create a sub-Web at any level in your FrontPage-based Web's structure. While a sub-Web will appear in a visual representation of your root Web's hierarchy, FrontPage treats each sub-Web as a separate entity with its own owner and list of authorized users. By default, when an administrator creates a new sub-Web, it inherits the user list and security of its parent Web. Using the Server Extensions, however, an administrator can set separate security for a sub-Web and assign it its own list of authorized users.
There are two ways to create a sub-Web. The first is to simply create a new Web. If you have a Web open and choose File:New:Web, FrontPage offers to create a new Web directly under the root folder for the current Web (if there is a current Web). If no Web is open, you must specify a Web server in the "New" dialog and the level at which to create the Web. The initial URL displayed will be relative to the server root. The second way to create a sub-Web is to choose a folder in a current Web and convert that folder to a sub-Web.
Creating a virtual server is another way for an administrator to scale a FrontPage-based Web. Because a virtual server has its own security settings and its own user list, creating a virtual server is also a way for an administrator to limit access to certain Web content.
Creating a Virtual Server on Microsoft Internet Information Server (IIS) 4.0On Windows NT Server's 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.
Creating a Virtual Server on a Netscape ServerOn 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 Virtual Server on a UNIX Server
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:
fpsrvadm -o chown -h hostname-p port -xUser unixuseraccount -xGroup unixgroupaccount
Once you complete the set up of your FrontPage root Web structure and any sub-Webs, your next step is to set access permissions for those Webs. As part of the goal of making administration of FrontPage-based Webs easier, the Server Extensions allow you set access permissions and administer security remotely, without the need for server administration training.
FrontPage uses a role-based security model. For each FrontPage extended Web, the administrator defines and sets permissions for three levels of users: administrators, authors, and browsers (end-users). All permissions are cumulative-- that is, all authors also have browsing permission, and all administrators also have authoring and browsing permissions. The implementation of this model varies somewhat depending on the platform of the server on which the Server Extensions are installed. For all platforms, however, the Server Extensions leverage the server's existing security model.
In FrontPage, the list of administrators, authors, and browsers is defined for each FrontPage-extended Web. All FrontPage sub-Webs either inherit the permissions (list of administrators, authors, and browsers) of their parent Webs or use their own unique permissions.
On the Microsoft Windows NT operating system, user and group accounts are assigned privileges and are granted varying levels of access to system resources. IIS implements access control based on user accounts set up under Windows NT. Users must present their credentials (user name and password) for identification before being granted access to a Windows NT resource. Group accounts do not have passwords but are a convenient way to grant privileges to a collection of user accounts.
An access control list (ACL) is a list of entries that identify user names or groups. By setting an ACL on a folder, you identify which users and groups have access to the applications in that folder and what level of access each user and group has. When a user tries to use an application on Windows NT, that application is assigned a token containing that user's information. If the user information in the token does not appear in the ACL for the folder, Windows NT denies the user access to the application.
Note Windows NT supports two types of file partitions: NTFS and FAT file partitions. ACLs are only supported by NTFS. Because FrontPage Server Extensions security is based on ACLs, you should use NTFS on a system on which you are hosting World Wide Web services using IIS and FrontPage.
On Windows NT, when an application runs, it impersonates the user who has been authenticated to use that application. Then, when the application attempts to invoke another application or use a system resource, such as the file system, access to the new application or system resource is granted or denied based on the permissions of the impersonated user. By forcing an application to run as a user, Windows NT ensures that applications only have access to system resource that would be accessible to that user. Also, impersonation reduces the number of times a user is required to enter their password as different applications and system services are invoked once the user has been authenticated.
Setting Permissions with the Windows NT Security ModelFrontPage relies on ACLs to give FrontPage Web administrators, authors, and end-users the proper access to content and programs in FrontPage-extended Webs:
Along with the ACLs in the root directory of every sub-Web, FrontPage sets ACLs throughout the content of a Web. These ACLs control access to executable content files, form results, and other content.
You set the ACLs for a FrontPage-based Web using the FrontPage client's Permissions command. When an administrator adds new users and groups, this command makes the Windows NT-based computer account list available. In FrontPage, you can set up a restricted list of users and groups that does not expose the entire contents of the Windows NT-based computer and domain account lists. This feature allows you protect confidentiality within your user communities.
Most UNIX Web servers maintain a list of users who have permissions to use the Web server. This access control file is maintained by the Web server and is entirely separate from the list of users and groups who can log on to the computer interactively.
Note Many Web servers that run on Microsoft Windows 95 and Microsoft Windows NT also use the UNIX security model. These include the following Web servers for which the FrontPage Server Extensions are available: FrontPage Personal Web Server, Netscape FastTrack, Netscape Enterprise, Netscape Communications, Netscape Commerce, and O'Reilly WebSite. The description of the UNIX security model also applies to those servers.
A Web server's access control file contains names and passwords for each user and detailed information about the content, CGI scripts, and other resources that each user is allowed to access. On Apache and NCSA Web servers, the file is .htaccess, and on Netscape servers it is .nsconfig. The access file associates users, groups, and IP addresses with various levels of permissions: GET (read), POST (execute), PUT (write), and DELETE. For example, a FrontPage author would have permission to use HTTP POST commands (to access the FrontPage Server Extensions and save new content), and a user with browse permissions would be permitted to use HTTP GET commands (to read content). The lists defining members of each group (such as FrontPage authors) are defined in separate files that are pointed to from the access file.
Multiple access files are often stored on a Web server. Each access file provides security for the directory containing it and for any subdirectories that do not contain their own access files. By creating access files throughout a Web server's content, different sets of users with varying levels of permissions can be given access to different areas of the server.
The FrontPage Server Extensions are stored in three directories below the root of every FrontPage-extended Web:
The server's configuration file needs to be modified to mark _vti_bin, _vti_adm, and _vti_aut as executable directories. A Web server administrator initiates and controls this operation using the FrontPage Server Administrator utility fpsrvadm.exe.
To reduce the total amount of disk space needed to support FrontPage-extended Webs, the FrontPage executables stored in the various _vti_* directories are stub executables. They each invoke a full executable file installed in the directory /usr/local/frontpage/version4.0/exes.
The access control files for the Server Extensions reside in the directories that contain the three Server Extension executables. The permissions set in these access control files determine who can access those directories, and therefore who can use which components of the Server Extensions. For example, users granted access to the _vti_adm directory will have access to the administrative functions of the Server Extensions, and users granted access to the _vti_aut directory have access to the authoring functions. Most of the time, an administrator uses the FrontPage Permissions Manager to set permissions to these directories.
Microsoft FrontPage Server Extensions make administering and maintaining a FrontPage-based Web easier in several ways. Among other things, the Server Extensions allow you to perform administration functions remotely, automate some of the administration functions with scripting, make your Web scaleable, and create your own reports.
FrontPage Server Extensions let you take advantage of a layered administration model by setting a user up as an administrator. An administrator, using the FrontPage-based client along with the Server Extensions, can perform most of the administrative tasks for a FrontPage-extended Web. These tasks include setting up user accounts, setting user permissions, creating new Webs and sub-Webs, creating new virtual servers, and other tasks usually reserved for a server administrator. With FrontPage Server Extensions, a user can administer a Web without having the specialized knowledge and training of a server administrator.
Managing a FrontPage-based Web running on Microsoft Internet Information Server 4.0 and later is even easier, thanks to the Microsoft Management Console (MMC). MMC is an application with an Explorer-like interface that hosts administrative snap-ins from other applications. In essence, the MMC provides the framework, including a tree control and folder view, within which a snap-in can run. Snap-ins fill the tree control and the folder views, and can add actions to the context menus that appear when an administrator right clicks on a folder. An MMC snap-in is available for FrontPage-extended Webs running on IIS 4.0. Using this snap-in and the MMC, an administrator can access most of the Server Extensions' functions, all from a single, easy-to-use interface.
Although this snap-in is only available for Internet Information Server 4.0 and later, it provides several advantages that help to make managing and administering a FrontPage-based Web easier. For example, the MMC snap-in for the FrontPage Server Extensions provides a convenient interface with which an administrator can easily perform just about any Server Extension function, such as setting access permissions, creating user lists, or creating new Webs.
The MMC snap-in for the FrontPage Server Extensions also provides consistency and integration with other Microsoft services, such as IIS.
FrontPage Server Extensions provide two methods for remotely administering a FrontPage-based Web and for administering all other servers besides IIS 4.0.
HTML Administration FormsYou can use the HTML Administration Forms to 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 fpremadm UtilityThe fpremadm utility supports remote administration of the FrontPage Server Extensions from the command line. It installs, updates, removes, and checks the FrontPage Server Extensions on FrontPage root Webs and sub-Webs, and performs other administrative FrontPage Web. The fpremadm.exe file is only provided for machines running Windows. There is no UNIX version of this utility.
FrontPage Server Extensions support scripts that allow you to create batch files that automate certain administrative tasks. For example, if your users need access to ten different servers, you would have to run a simple add-user function ten times every time you added a new user. To avoid this, you can create a batch file that adds a new user to all ten servers at a time. Similarly, you could create a batch file to run other common commands, such as a "check" command, on all of your servers at once.
Performance problems with a FrontPage-based Web are usually caused by having too many authors trying to access a Web simultaneously. One way to reduce this problem is with sub-Webs. By allowing sub-Webs, FrontPage Server Extensions let you to add files and/or users to your Web without sacrificing performance. While there are no strict guidelines for when to divide a Web into sub-Webs, a rule of thumb is to watch performance. When your Web begins to experience performance problems, you should consider creating sub-Webs. The point at which a FrontPage-based Web begins to have performance problems varies depending on the specific circumstances of a Web's configuration and use.
Microsoft FrontPage comes with several built-in reports, including a report of your Web's broken links, and a report that finds old pages. You may find that you need other reports specific to your own Web. FrontPage Server Extensions include a Web Object Model that lets you create custom reports using Microsoft Visual Basic® development system scripts. So, for example, you could create your own report that tells you which of your pages include copyright information.
FrontPage Auto features are functions that can be applied across an entire FrontPage-based Web with a single action, such as changing the design theme of a Web. For example, you might create a Web with the purpose of sharing information informally among a small group, on which you might use a simple default theme. Later, as the site draws more traffic, you can use FrontPage Auto features to create a custom theme and apply the through universally across your Web.
Microsoft FrontPage 2000 Server Extensions can play an important role in helping you implement Webs that meet the needs of your organization. When designing FrontPage Server Extensions, the architects put effort into understanding the business issues related to Web site deployment, including workgroup collaboration, remote computing, and the costs related to server administration.
On the technical side, the FrontPage Server Extensions address critical compatibility issues that enable you to integrate the Microsoft FrontPage Web site creation and management tool with your existing hardware and software and scale your Webs into more manageable sub-Webs as your content base grows. Overall, the newest version of Microsoft FrontPage with the Server Extensions provides the security, manageability, and rich features to meet Web publishing needs going into the year 2000.
For specific details on implementing the FrontPage Server Extensions, see the FrontPage Server Extensions Resource Kit.
Did you find this material useful? Gripes? Compliments? Suggestions for other articles? Write us!
© 1999 Microsoft Corporation. All rights reserved. Terms of use.
Back to top