Site Administration

Site administration is for configuration of one particular Web site. Using site administration, you can configure what users have access to your Web site and specify the type of information logged about who is visiting your Web site, what pages they are viewing, and so on.

To administer the security of a FrontPage Web site, you use the Microsoft SharePoint Administrator (see Figure 17.7) if you are using the FrontPage 2002 Server Extensions or the SharePoint Central Administration (see Figure 17.8) if you are using Windows SharePoint Services. Both are located in Administrative Tools, but you can also access them by opening the Web site in FrontPage and then selecting Tools, Server, Administration Home after opening the Web site in FrontPage.

Figure 17.7. Site Administration for a FrontPage Server Extensions 2002 Web site.

graphics/17fig07.gif

Figure 17.8. Site Settings for a Windows SharePoint Services Web site.

graphics/17fig08.gif

For details on how to open the Web site in FrontPage, see "Opening and Working with Existing Web Sites," p. 283.


When using a FrontPage Server Extensions 2002 Web site, setting up permissions for your Web site changes the file and folder permissions on the operating system itself according to predefined roles. When using a Windows SharePoint Services site, all the content is stored in a Microsoft SQL Server database, so the usual rules don't apply. In this section, we will cover only the permissions for a FrontPage Server Extensions 2002 Web site.

For details on managing a Windows SharePoint Services 2.0 Web site, see "Windows SharePoint Services 2.0," p. 943.


Roles and Rights An Overview

Five built-in roles are available to you on a FrontPage Server Extensions Web site. A role is a FrontPage group that has certain rights to a Web site. These rights can range from being able to simply browse the site to being able to administer and change permissions on the Web site. The roles that are provided by default and their default rights are as follows:

  • Browser This is the lowest level of access to a FrontPage Web site. A user who has been given only the Browser role can browse the Web site, but cannot post to any Web site discussions or modify the site content in any other way.

  • Contributor A Contributor has all the rights available to a Browser, but she can also view and post to discussions on the Web site.

  • Author An Author can open the Web site in FrontPage and add, edit, and delete pages, but she can't apply a theme, a shared border, or link style sheets to the Web site.

  • Advanced Author An Advanced Author can perform any editing task on the Web site, but she cannot set permissions on the Web site. An Advanced Author also cannot create new Web sites or subsites. This is the level of access that most hosting companies provide FrontPage users.

  • Administrator An Administrator has all the available rights on a Web site.

TIP

A server administrator can configure the FrontPage Server Extensions so that they don't use roles to implement security. When roles are turned off, the Server Extensions will only allow the Browser, Author, and Administrator roles.


NOTE

For more information on Windows users and groups and Windows administration, read Windows 2000 User Management from Que Publishing.


The twelve rights that can be granted to members of a particular role are as follows:

  • Author Page Users with this right can open the Web site in FrontPage and create, edit, or delete Web pages and folders.

  • Browse Users with this right can browse to any Web page in the Web site.

  • Set Source Control Users with this right can configure the source control database for Web sites that are under source control.

  • Theme Web Users with this right can apply a theme to the Web site.

  • Border Web Users with this right can apply a border to the Web site.

  • Link Style Sheets Users with this right can link style sheets to the Web site.

  • Configure Access Users with this right can manage permissions and roles for the Web site, but they cannot create new users.

  • Create Accounts Users with this right can create new users for the Web site, which are created as local Windows accounts on the Web server.

  • Manage Server Health Users with this right can use the Server Health tool.

  • Manage Usage Analysis Users with this right can manage Usage Analysis settings.

  • Manage Subweb Users with this right can create new subsites, rename existing subsites, and delete subsites.

  • Recalc Web Users with this right can run the Recalculate Hyperlinks command to recalculate the Web site.

For more information on the Server Health and Usage Analysis tools, see "Configuring Usage Analysis Settings" and "Managing Server Health" in this chapter, p. 339-340.


NOTE

For more information on FrontPage Server Extensions, see the SharePoint Team Services Administrator's Guide available at http://fpserk.frontpagelink.com.


A user can be a member of more than one role and her rights are cumulative. You can very easily change the default rights assigned to a role, as you will see later, and you can also create your own roles and change the list of rights that are available for users of your Web site. All of this will be discussed in detail as you progress through the chapter.

Creating Users and Roles

To access the Site Administration page open your root Web site in FrontPage (that is, http://localhost) and select Tools, Server, Administration Home.

You should now see the Site Administration page as shown previously in Figure 17.7.

For details on opening a Web site in FrontPage, see "Opening and Working with Existing Web Sites," p. 283.


Changing Anonymous Access

The first link in Users and Roles is the Change Anonymous Access Settings link. (If this is not your first link, make sure that you opened the root Web site and not a subsite.) Most Web sites allow for anonymous browsing, which means that you don't have to enter a username and password in order to browse the Web site. You can change whether your Web site allows anonymous access using the Change Anonymous Access Settings link.

Click the Change Anonymous Access Settings link to display the Change Anonymous Access Settings page as seen in Figure 17.9. From here, you can choose whether anonymous browsing is enabled and what role is used for anonymous browsers. In almost all cases, you will want to use the Browser role for anonymous browsing because it gives the least amount of permissions to people. If you turn off anonymous access, your site will not be accessible unless users are authenticated either by entering a valid username and password, or by having a valid user credential passed automatically from a Windows login.

Figure 17.9. The Change Anonymous Access Settings page allows you to prevent unauthorized users from browsing your site.

graphics/17fig09.gif

NOTE

If you want to create a Web site where people can sign up for access and receive a password, using Web site permissions is not your best option. Instead, you can use ASP or ASP.NET to authenticate users against a database. Doing so will require skills in ASP or ASP.NET.


NOTE

For more information on Anonymous access and other authentication methods of Internet Information Services, read Internet Information Services Administration from Que Publishing.


Adding and Deleting Accounts

The next link is the Click Here to Add or Delete Accounts link, along with an informational message indicating how many accounts you've created and how many are allowed. (If this is not your second link, make sure that you opened the root Web site and not a subsite.)

By default, the FrontPage Server Extensions allow an unlimited number of user accounts, but the Web site can be configured so that the number of accounts for the site are limited to a specific number.

For more information on configuring user account limits, see "Virtual Server Administration," p. 345, later in this chapter.


When you click the Click Here to Add or Delete Accounts link, you are taken to the Manage Virtual Server Accounts page (see Figure 17.10), where you can see the accounts that you have created, add new accounts, and delete existing accounts. Accounts added here are Windows accounts that can then be added to roles so that they can access your Web site.

Figure 17.10. Creating new accounts for access to your site is done on the Manage Virtual Server Accounts page.

graphics/17fig10.gif

Managing Users

The next link in Users and Roles is Manage Users. Using this link, you can add new users to your Web site or make existing users a member of a role. FrontPage grants access by checking the user's group membership in Windows. The FrontPage Server Extensions create Windows groups on the Web server to manage access to the Web site. Each group maps directly to a particular role. The groups for the default roles are as follows:

  • OWS_##########_admin Administrator

  • OWS_##########_advauthor Advanced Author

  • OWS_##########_author Author

  • OWS_##########_collab Contributor

  • OWS_##########_browser Browser

The number (#) signs in each group are replaced with a unique number for the site. The FrontPage Server Extensions create a group for each Web site with unique permissions on the Web server. However, the group is only created once a user is assigned to that role.

If all members of a particular role are removed, the group representing that role is not deleted. It is maintained so that it can be used if a user is added to the role at a later date.

NOTE

A server administrator can configure the Server Extensions so that machine groups are not created to implement security. In those cases, the Server Extensions will set each user's permissions individually.


To assign a user to a particular role

  1. Click Manage Users.

  2. Click Add a User. The Add a User page is displayed as shown in Figure 17.11.

    Figure 17.11. The Add a User page is where you add users for your Web site.

    graphics/17fig11.gif

  3. In the User Name box, enter the username to use for your new user.

  4. Enter the password for the new user and enter it again to confirm it.

  5. Select a role for the user. You can select multiple roles if needed.

  6. Click Add User to add your new user.

Your new user should now appear in the Manage Users page as shown in Figure 17.12. In this example, the account appears as DADATOP\TestUser. DADATOP is the name of the machine or domain, and TestUser is the name of the user.

Figure 17.12. The TestUser user has been added to the Advanced Author role.

graphics/17fig12.gif

graphics/troubleshooting_icon.jpg

If you are prompted for username and password after clicking Manage Users and you are not able to access the page, see "Not Authorized to Manage Users" in the "Troubleshooting" section of this chapter.


Managing Roles

The Site Administration page also provides access to manage the roles in your Web site. Using the Manage Roles page, you can select which rights are available to a particular role. To add or remove rights from a particular role

  1. Click the Manage Roles link to display the Edit Role page shown in Figure 17.13.

    Figure 17.13. The Edit Role page provides an interface for customizing roles.

    graphics/17fig13.gif

  2. Click the role that you want to edit.

  3. Place a check in the check box for the right you want to assign to the role and remove the check from any right that you want to remove from the role.

  4. Change the description to match the new role's rights.

  5. Click Submit to commit changes to the role.

FrontPage stores your role configuration inside a file called roles.ini, which is located in C:\Documents and Settings\All Users\Application Data\Microsoft\Web Server Extensions\50\W3SVC1 on the Web server. The roles.ini file is used to reapply permissions when you run the Server Health function and choose to tighten security. Therefore, if you manually alter any permissions in your FrontPage content area, the Server Extensions will change them back to what they were prior to your modifications as soon as you check server health.

Security and FrontPage Server Extensions

Windows computers control access to files and folders using file system security and permissions. Every file has permissions that determine which users have rights to that file and what level of access they have.

The permissions required to enable the FrontPage Server Extensions to operate correctly are extremely complicated. If you attempt to manage the permissions manually instead of using FrontPage, it is common to unintentionally either open security holes in the Web site or restrict access to it so that it cannot be browsed successfully.

To correct problems caused by incorrect permissions, the Server Extensions store all the permission settings inside of the roles.ini file. The Server Extensions can use the information in the roles.ini file to reapply permissions so that the Server Extensions will function correctly.

For more information on reapplying permissions using the information stored in the roles.ini file, see "Server Health" later in this chapter.


CAUTION

Don't ever try to manually edit the roles.ini file. If you do, you can prevent your Web site from working correctly.


NOTE

If you're an ASP.NET developer, don't ever allow FrontPage to tighten security on your Web content. Doing so will remove the Windows account used to run ASP.NET from the permissions and will prevent your ASP.NET files from running.


To remove one or more roles, place a check in the box next to the roles you want to delete and then click the Delete Selected Role(s) link.

You can also create new roles by either copying and modifying an existing role, or creating a new role from scratch. Suppose that you want to give certain people only Author access to your Web site, but you also want them to have the ability to create new sites. In that case, you can create a new role that will have all the same rights as the Author role, but will also have the right to create new sites. After you've created the role, anyone you assign to it will have the same rights as someone in the Author role, but they will have the additional right of being able to create new sites.

To copy an existing role, click the name of the role and then click the Copy Role button. You will be taken to the page>>Copy the Role <Role> page (see Figure 17.14), where a copy of the role is displayed and ready for editing. Enter a new role name and a description before creating your new role. If you want the users of the existing role to be copied to the new role, check the Copy Users from <Role> check box prior to creating the new role.

Figure 17.14. Copying roles makes creating new roles based on existing roles easy.

graphics/17fig14.gif

If you choose to create a new role from scratch, click the Add a Role link on the Manage Roles page. Enter a name and description for your new role and select the rights you want to assign to the role. If you select a right that requires another right, the required right will be selected automatically. Once you have created your new role, you can assign users to that role using the Manage Users link, as seen in Figure 17.15.

Figure 17.15. Jack is being added to the Managers role a new role that was just created.

graphics/17fig15.gif

NOTE

When you add a new role, the Server Extensions create a new group in Windows for that new role.


Sending Invitations

The final link in the Users and Roles section of Site Administration is the Send an Invitation link. Using this link, you can send a personalized invitation to anyone to whom you have given access to your site. The process is a three-step wizard.

  • Specify email address(es) of anyone you are inviting to your site.

  • Verify the Windows account for that person. Your invitees must have accounts on the server before you invite them, so if you haven't created accounts yet, use the Manage Users link to do that before you send the invitation.

  • Fill out a personal greeting and assign a role for your invitees.

The Server Extensions will send an email out to your invitees with the URL to your site, the customized greeting you entered, and a brief description of their access level.

If you get an error telling you that you must set up email before sending an invitation, see "Unable to Send Invitations" in the "Troubleshooting" section of this chapter.

Configuring Usage Analysis Settings

The next section in Site Administration is the Configure Usage Analysis Settings section. This section is used to configure the usage analysis for the Web site. Usage analysis provides you with details on how many hits a Web site has gotten, what browsers are being used to access it, the most popular page in the site, and so on. By checking the Process Log File Data for Full Days Only check box, you can ensure that you are getting accurate data based on full days of hit analysis.

As seen in Figure 17.16, you can configure usage analysis to run daily, weekly, or monthly. You can also configure the Server Extensions so that they delete old usage analysis data after a specific amount of time. The default is 12 months.

Figure 17.16. Usage Analysis data is collected at regular intervals according to the schedule you set.

graphics/17fig16.gif

TIP

Usage analysis data can end up using substantial disk space, so you will want to keep a close eye on how much space is being used by your data and make a determination as to how long you want to keep it before it's deleted.


The usage analysis settings also allow you to configure an email address that will receive a confirmation email as soon as usage analysis data has been successfully collected.

For more information on analyzing usage analysis data in FrontPage's Reports view, see "Reports View," p. 70.


Managing Server Health

The Server Health section of Site Administration provides access to all the functions you need to keep your site running at full speed. The first item in this section is a label that indicates whether Server Health is on. This setting refers to the scheduling of the Check Server Health function.

NOTE

You don't have to schedule the Check Server Health function to run at regular intervals. However, if you have other FrontPage users editing content on your Web server, it's not a bad idea.

For example, if someone were to use FTP to upload content to a Server Extensions site, forms and other Server Extensions components might be broken. By running a regular Check Server Health function, you can head off problems caused by poor authoring practices.


Click the Change Server Health Settings link to access the Change Server Health Settings page as seen in Figure 17.17. From here, you can turn Server Health on and then configure how often it runs. Unfortunately, there isn't an option to email an administrator if an uncorrectable error is encountered, but a regular check of server health is beneficial to head off such problems before they start.

Figure 17.17. The Change Server Health Settings page helps keep your Web site running at top efficiency.

graphics/17fig17.gif

What Happens When You Check Server Health

If you click the Check Server Health link, you can see just what is checked and repaired when the Check Server Health function is run.

  • Reapply File Security Settings This option has no detect option because it really isn't applicable. When the Repair box is checked for this option, FrontPage will reapply all permissions according to the roles you have configured and the users who are members of those roles.

  • Verify Existence of Webs When this function is run, the Server Extensions check the services.cnf file that is located in the _vti_pvt folder of the root Web site. Inside that file is a list of all subsites that FrontPage thinks exist. The Server Extensions then check to see if the Web sites actually exist. If they do not, FrontPage removes them from the services.cnf file.

    CAUTION

    You should be very careful about repairing problems found if you have content that is located on remote file systems. If the remote file system is unavailable for some reason, thereby causing FrontPage to remove the Web site from the services.cnf file, the Web site will no longer be recognized as a FrontPage Web site.


  • Check Roles Configuration This function checks for any problems related to roles and user accounts. It synchronizes the existing user accounts with the roles to which they are assigned and corrects any discrepancies.

  • Tighten Security This check ensures that only those users who are supposed to have access to your files actually have access. Web server administrators will often change permissions on files and folders within Windows instead of within FrontPage. In doing so, they may unintentionally give a user permission to a part of your Web site to which they should not have access.

    When the Tighten Security function is used, if a user isn't a member of a role that should have access to a particular file or folder, she is removed from the permissions list.

    CAUTION

    ASP.NET developers should be very careful about running a repair on this function because it will remove the account used to run ASP.NET from your Web site permissions, thereby rendering your ASP.NET pages inoperable. Making the account that runs ASP.NET a Browser on the site will prevent this, but it can make administration more difficult for ASP.NET developers.


  • Check Anonymous Access This check ensures that anonymous users do not have more access than they should. The Server Extensions allow you to configure a specific role for anonymous users. This check will ensure that the role you configure is enforced and that anonymous users aren't granted additional rights.

Recalculating the Web Site

The last item in the Server Health section is the Recalculate the Web item. This item performs the same function as the Recalculate Hyperlinks function in FrontPage. To many FrontPage users, this function is a mystery.

The Recalculate the Web function performs a whole series of checks against the Web site and corrects many possible problems. It checks the .cnf files for the Web site to make sure that there aren't any configuration problems, and it reconnects all FrontPage forms and browse-time Web components to the Server Extensions. If one or more of your FrontPage components is displaying the component name inside of square brackets (that is, [FrontPage Save Results Component]), a good first troubleshooting step is to Recalculate the Web site. That will often correct the problem.

Configuring Version Control

The Configure Version Control link takes you to the Configure Version Control page, where you can configure the source control system for your Web site. A source control system provides developers with the ability to check out files and to maintain a database of previous versions so that they can roll back to a previous version if they need to.

FrontPage has a built-in source control system that is a fairly lightweight solution and not really a good choice for a serious developer's shop. For a more robust solution, Server Extensions will also integrate with Microsoft Visual SourceSafe (VSS).

If VSS is available and configured correctly, the Configure Version Control page will have the option to use an external source control system. That external system is VSS.

For more information on using version control with FrontPage, see "Checking Documents In and Out," p. 624.


Managing Subsites The Subwebs Section

The Subwebs section of Site Administration provides you with the tools necessary to create new subsites, merge subsites (convert a subsite into a folder), and delete subsites. You can also access the Site Administration page of any of your subsites by clicking on the subsite name.

TIP

Beginning with FrontPage 2003, Microsoft refers to Web sites created under the root Web site as subsites. Because Microsoft is no longer releasing new versions of the Server Extensions, the terminology inside the Server Extensions dialog boxes has not changed, which can be confusing. Just remember that subwebs and subsites are the same thing.


To create a new subsite, click the Create a Subweb link to display the Create a Subweb page, as seen in Figure 17.18. Enter the name for the new subsite and select whether the new subsite should inherit the permissions from its parent or use unique permissions. If you choose the option to use unique permissions, you must also specify the username for an Administrator for the new subsite.

Figure 17.18. The Create a Subweb page provides the tools necessary to create new FrontPage subsites.

graphics/17fig18.gif

NOTE

FrontPage users will find it more convenient to create new subsites inside FrontPage itself. The Subwebs Section of Site Administration is typically used by server administrators who do not have access to a copy of FrontPage.


To convert an existing subsite into a folder, click the Merge a Subweb link to display the Merge a Subweb page as seen in Figure 17.19. Select the subsite from the Web Name dropdown and click the Merge Subweb button to convert it to a folder.

Figure 17.19. The Merge a Subweb page converts a subsite to a regular folder.

graphics/17fig19.gif

To delete a subsite, click the Delete a Subweb link to display the Delete a Subweb page as shown in Figure 17.20. Select the subsite from the Web Name dropdown and then click the Delete Subweb button. The subsite and any child subsites will be permanently deleted. Remember, there is no Recycle Bin in FrontPage, so once you delete the subsite, there is no way to retrieve it.

Figure 17.20. Delete a subsite from the Delete a Subweb page.

graphics/17fig20.gif

The Subwebs section also contains a list of all subsites of the current Web site. By clicking the name of the subsite, you are taken to the Site Administration page for that subsite. As shown in Figure 17.21, the Site Administration page for a subsite does not contain all the same options available to you on the root Web site's Site Administration page. Instead, you have the following tools available on a subsite's Site Administration page:

  • Change Subweb Permissions Allows you to configure whether the subweb inherits permissions from its parent or has its own unique permissions.

  • Recalculate the Web Recalculates hyperlinks on the subsite.

  • Configure Version Control Sets the version control options for the subsite.

  • Create a Subweb Creates a new subsite as a child of the current subsite.

Figure 17.21. The Site Administration page for a subsite contains fewer options than the root Web's Site Administration page.

graphics/17fig21.gif



Special Edition Using Microsoft Office FrontPage 2003
Special Edition Using Microsoft Office FrontPage 2003
ISBN: 0789729547
EAN: 2147483647
Year: 2003
Pages: 443

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net