Managing SharePoint Portal Server 2003

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Published: June 9, 2004

This is a sample chapter from the Microsoft SharePoint Products and Technologies Resource Kit. You can obtain the complete resource kit (ISBN 0-7356-1881-X), which includes a companion CD-ROM, from Microsoft Press.

If one thinks of Microsoft Windows SharePoint Services as providing a collaboration engine targeted to helping members of individual teams and small workgroups collaborate and share data, one can look at Microsoft Office SharePoint Portal Server 2003 as the product that brings those teams and workgroups together, allowing them to find each other and to leverage each other’s work. In fact, part of the intent of the portal product is to provide a central place for all workers in an organization to quickly and easily find information in workspaces that they might not be members of.

When looking at and using Microsoft Windows SharePoint Services, users had no way to easily find all the team sites that were created and it was left to the administrator to create a Web page of links that pointed to those team sites. Also, searching for data is always limited to the team site from which you do the search request.

Essentially, Microsoft SharePoint Portal Server 2003 takes all the Windows SharePoint Services sites and makes them navigable, as well as searchable from the central portal site. Furthermore, a new kind of site is introduced, called portal areas, which can be created as part of the portal site. Using special area templates, these portal area sites include additional enterprise-level features such as support for alerts based on users’ subscriptions to lists and list content, as well as support for content displayed based on users’ audience membership. Another kind of site is also introduced, called personal sites, wherein each user is given his own site to use for private storage of data with the capability of making that data available to other users of the portal.

In this chapter, we first will learn how a portal system administrator can make use of and manage these additional features. Starting on the Site Settings page of the portal site, we will look at some differences between portal-level security and team site security and the special considerations that should be made when managing portal-level security. We will also cover the management tasks related to the alert feature. This topic will show how an administrator can help individual users manage their alerts. We will then look at how to change the default look of the portal site to a customized one by assigning custom logos and custom cascading style sheet files. From there, we will see how to manage portal site content with respect to area pages, the Topic Assistant, and audience targeted links. Finally, we will look at how to manage audience recalculation and show how administrators can manage users’ personal sites. For a discussion on searching and indexing, please refer to Chapter 21, “The Architecture of the Gatherer,” and Chapter 22, “Managing External Content in Microsoft Office SharePoint Portal Server 2003.”

On This Page

Administering Portal Site Settings
General Settings
Portal Site Content
Search Settings And Indexed Content
User Profile, Audiences, And Personal Sites
Changing Owners of Portal Sites
Summary

Administering Portal Site Settings

To administer a portal site, use the Site Settings link found at the top right-hand corner of any portal area page. Only users with portal administrator and area administrator type permissions will see this link. The ensuing Site Settings page is divided into four sections called General Settings, Portal Site Content, Search Settings, and Indexed Content. These sections are followed by sections named User Profile, Audiences, and Personal Sites. Each section will be discussed in detail next.

General Settings

The General Settings section contains links to manage which users are explicitly allowed to access the portal site, as well as a link allowing the administrator to control how anonymous access is handled by the portal site. The ability to manage the alert feature of a portal site is provided here as well. Figure 18-1 shows the General Settings section of the portal site’s Site Settings page.

Figure 18-1.The General Settings section of a portal site’s Site Settings page

Manage Users

As a portal administrator, you will want to control who can access the portal site and what level of privilege they have with respect to accessing and modifying content. Just as with Windows SharePoint Services, administrators can add users and groups from Microsoft Windows NT or Active Directory domains as users of the portal site. Permissions are assigned in the same way as in Windows SharePoint Services sites by associating users and groups to Site Groups. Please refer to Chapter 16, “Windows SharePoint Services Site Administration,” for a discussion on how to add users using this interface.

Manage Security And Additional Settings

This link takes the portal administrator to the Manage Security And Additional Settings page, which contains many links useful for day-to-day management of the portal. This page is also divided into five grouped sections of links. Figure 18-2 displays the Manage Security And Additional Settings page and shows two of the five grouped sections of links found there.

Figure 18-2.The Manage Security And Additional Settings page

The full list of grouped sections and their main purposes are as follows:

Users And Permissions.

• Used to manage who can access the portal and with what privilege

Templates And Web Parts.

• Used to manage a site’s or area’s Web Parts as well as Web Parts installed for the whole portal site

Discussion Settings.

• Used to view and delete document discussions

Storage Space.

• Used to identify where the most storage-intensive content is found, and offers the ability to delete it as well

Regional Settings.

• Used to set locale, default search result sort order, and time zone of the portal server

Users And Permissions

Controlling who can access the portal site and what level of access they will have to its content is performed through the Manage Users and Manage Site Groups links, which work exactly as they do in Windows SharePoint Services team sites. Please refer to Chapter 16 for more detail on managing users and site groups.

  Despite the security similarities between Windows SharePoint Services and SharePoint Portal Server, it is important keep in mind that while the former has the concept of Sites and Site Collections, the latter does not. A portal is a site collection and an area is a sub-web.

The Show User Information link, which does not exist with Windows SharePoint Services, takes the administrator to a page summarizing all users that have a Microsoft SharePoint Portal 2003 profile. A profile is created either when an authenticated user successfully accesses the portal site for the first time or automatically by the profile import process (which creates a profile for users based on Active Directory) if it has been enabled by the portal administrator. By following the link for a listed user, the administrator can edit the user information by adding notes about the user and can even designate the user as a Site Collection Administrator.

  You might notice that user accounts that have been granted access to portal areas and team sites continue to show in site groups and permission lists in the portal site even after they have been deleted from the domain. The only two ways to get rid of them are to delete each entry in every site and site group or to delete them from the Manage Site Collection Users page, which will effectively remove them from all sites and site groups in that collection.

One of the few differences in portal security from Windows SharePoint Services security is the existence of the additional Content Manager site group. By default, members of the Content Manager site group can approve or reject content posting requests and manage area settings. In addition, Content Managers can target areas for viewing by one or more audiences, which will be discussed later.

Another security-related difference relates to the permission set that can be granted to a portal’s site group. For example, users can be granted or denied the Use Personal Features permission, which allows administrators to control which users or groups can use the portal site’s alert feature and the portal site’s personal site feature. Other permissions that do not exist for team sites relate to portal site feature management. Table 18-1 lists the differences in the two sets of permissions.

Table 18-1. Rights Differences Between Windows SharePoint Services and SharePoint Portal Server 2003

Windows SharePoint Services Rights	Description
Manage List Permissions	Grant, deny, or change user permissions to a list
Manage Lists	Approve content in lists, add or remove columns in a list, and add or remove public views of a list
Cancel Check-Out	Check in a document without saving the current changes
Add Items	Add items to lists, add documents to document libraries, add Web discussion comments
Edit Items	Edit items in lists, edit documents in document libraries, edit Web discussion comments in documents, and customize Web Part Pages in document libraries
Delete Items	Delete items from a list, documents from a document library, and Web discussion comments in documents
View Items	View items in lists, view documents in document libraries, view Web discussion comments, and set up e-mail alerts for lists
Manage Site Groups	Create, change, and delete site groups, including adding users to the site groups and specifying which rights are assigned to a site group
View Usage Data	View reports on website usage
Create Subsites	Create subsites such as team sites, Meeting Workspace sites, and Document Workspace sites
Manage Web Site	Grants the ability to perform all administration tasks for the website as well as manage content and permissions
Add and Customize Pages	Add, change, or delete HTML pages or Web Part Pages, and edit the website using a Windows SharePoint Services compatible editor
Apply Themes and Borders	Apply a theme or borders to the entire website
Apply Style Sheets	Apply a style sheet (.css file) to the website
Browse Directories	Browse directories in a website
Use Self-Service Site Creation	Create a website using Self-Service Site Creation
View Pages	View pages in a website
Manage Personal Views	Create, change, and delete personal views of lists
Add/Remove Private Web Parts	Add or remove private Web Parts on a Web Part Page
Update Personal Web Parts	Update Web Parts to display personalized information
Create Cross-Site Groups	Create a group of users that can be granted access to any site within the site collection
SharePoint Portal Server Rights	Description
View Area	View an area and its contents
View Pages	View pages in an area
Add Items	Add items to lists, add documents to SharePoint document libraries, add Web discussion comments
Edit Items	Edit items in lists, edit documents in SharePoint document libraries, and customize Web Part Pages in Share Point document libraries
Delete Items	Delete items from a list, documents from a document library, and Web discussion comments in documents
Manage Personal Views	Create, change, and delete personal views of lists
Add/Remove Personal Web Parts	Add or remove Web Parts on a personalized Web Part Page
Update Personal Web Parts	Update Web Parts to display personalized information
Cancel Check-Out	Check in a document without saving the current changes
Add and Customize Pages	Add, change, or delete HTML pages or Web Part Pages, and edit the portal site by using a Windows SharePoint Services compatible editor
Create Area	Create an area on the portal site
Manage Area	Delete or edit the properties for an area on the portal site
Manage Area Permissions	Add, remove, or change user rights for an area
Apply Style Sheets	Apply a style sheet (.css file) to an area or the portal site
Browse Directories	Browse directories in an area
Create Personal Site	Create a personal SharePoint site
Create Sites	Create SharePoint sites by using Self-Service Site Creation
Use Personal Features	Use alerts and personal sites
Manage Alerts	Change alert settings for the portal site, and manage alerts for users
Manage User Profiles	Add, change, or delete user profile information and properties
Manage Audiences	Add, change, or delete audiences
Manage Portal Site	Specify portal site properties and manage site settings
Manage Search	Add, change, or delete index and search settings in the portal site
Search	Search the portal site and all related content

As you read through this chapter and learn about all the management responsibilities you will have as an administrator of a portal site, you will undoubtedly want to delegate some of those responsibilities. You can achieve this delegation of responsibilities by creating custom site groups that have one or more of the five additional rights that pertain to portal area management permissions:

Manage Alerts.

• Privilege to change alert settings for the portal site and manage alerts for users

Manage User Profiles.

• Right to add, change, or delete user profile information and properties

Manage Audiences.

• Permission to add, change, or delete audiences

Manage Portal Site.

• Right to specify portal site properties and manage site settings

Manage Search.

• Privilege to add, change, or delete index and search settings in the portal site

The Change anonymous access setting link is required if the portal site administrator wants to enable anonymous access for the portal site. The Anonymous Access setting is set to Nothing by default, meaning that even if the virtual server hosting the portal site allows anonymous HTTP requests, the portal site will not honor the request. The requesting user would experience this kind of scenario by being prompted to log on to the portal site.

  Remember to turn on anonymous access both at the IIS virtual server as well as on the portal site’s Anonymous Access Settings page if you want users to access the portal site anonymously, such as in a public Internet portal scenario. You’ll also need to give the Anonymous user account Reader (or higher) permissions in the portal site. Also, note that anonymous, basic, and NTLM/integrated authentication on the virtual server with SPS is not supported by Microsoft.

Figure 18-3 shows that one of the following three levels of anonymous access can be chosen:

Areas And Content.

• Selecting this option allows all anonymous users to see all content, but it does not allow them to use the search feature. In this mode, the search Web Part does not show on the portal area pages for anonymous users.

Areas, Content And Search.

• This mode will allow anonymous users to see all content and will show the user the search Web Part at the top right of each portal area page.

Nothing.

• This is the default setting, which prevents anonymous users from entering the portal home page or any other portal area page.

  

  Figure 18-3.Changing the level of access to content for anonymous users of the portal site

Keep in mind that granting user access to the portal site does not necessarily grant access to the team sites or portal area pages listed by that portal site. While each team site is still administered as discussed in Chapter 16, the procedure to manage portal area security is slightly different. Figure 18-4 shows the News portal area page as seen by an administrator of that portal area along with the Manage Security link. By selecting the Manage Security link in the Action bar on the left side of the page, the administrator will be led to the area’s Manage Security Settings page, where he will be able to assign users, assign site groups, or allow inheritance of security from the parent area.

Figure 18-4.Controlling who can access portal areas

Each area page can be thought of as, and is, analogous to a team site. Just like team sites, portal areas can inherit permissions from their parent area or can have inheritance canceled by administrators. However, the method to cancel inheritance for portal area pages is very different from the way it is done on team sites. All the administrator needs to do is change the list of users and site groups that appears on the area page by adding or removing a user or site group, which effectively cancels inheritance for that portal area.

  Always read the description at the top of the portal area page to determine whether inheritance is in effect or has been blocked. Figure 18-5 shows the News area page with inheritance turned on. If the administrator turns inheritance off by changing the list of users and site groups, the description will state “these permissions are not inherited” and will also offer a link. Keep in mind that if you re-enable inheritance by selecting the link labeled “Inherit permissions from the parent area”, you will lose any changes you’ve made to the list of allowed users and site groups.

Figure 18-5.Manage Security Settings for the Area page with inheritance turned on

Templates And Web Parts

This section of the Manage Security And Additional Settings page is analogous to the Site Collection Galleries discussed in Chapter 16. The difference is that this section pertains to Web Parts and templates installed and available from the portal level down instead of only a SharePoint Services site’s Web Parts and templates, which have a per-virtual-server focus. The administrator can add and remove Web Parts and upload and manage site templates to the portal site. The advantage of uploading Web Parts and templates to the portal site is that they become available to all portal site users regardless of which server they are hosted on.

  One thing to remember, however, is that the administrator will still be responsible for installing Web Parts (and setting the Web Part security) on each front-end server. There is no “replication” of Web Parts that occurs.

Discussion Settings

Websites based on Microsoft Windows SharePoint Services include Web discussions, which are threaded discussions that allow users to collaborate on HTML documents or on any document that can be opened with a browser (such as .htm, .xls, .doc, and .ppt files) on a server running Windows SharePoint Services. Anyone with discussion permissions can attach comments to a Web page or any document that can be opened with a browser. Users place comments in the document or have them appear in the discussion pane at the bottom of the Web browser window.

  Web discussions are not the same as Discussion Boards and should not be confused with them. Discussion Boards are a feature of Windows SharePoint Services sites that provide a forum for conversing about any topics that interest your team and are created on the same Create Page location used to create lists and libraries. Web discussions are also supported by Windows SharePoint Services, but they relate to documents and Web pages only.

Anyone reviewing a Web page can use the Web Discussions toolbar in Internet Explorer to view and reply to any discussion. The Web Discussions toolbar is available in Microsoft Internet Explorer 4.0 or later to users of a Windows SharePoint Services–compatible client program, such as a Microsoft Office 2003 program.

  When you add discussion comments to a Web page, your text is stored in a database on a discussion server. The Web page you are discussing must be located on the same computer as the discussion server where your comments are stored.

The Manage Web Discussions page allows the portal administrator to list, access, and delete any document discussions pertaining to files stored in Document Libraries. The following tasks are possible:

• To see all discussion threads associated with your site, click All Web discussions, and then click Update.

• To see discussion threads filtered by a particular URL, type a path in the Web discussions in folder https://server_name/box, and then click Update.

• To view a particular discussion thread, click the URL for the thread.

• To delete a particular discussion thread, select the check box next to the thread, and then click Delete.

• To delete all discussion threads on your site, click Delete all discussions.

These tasks are particularly useful if you want to observe which documents have had discussions added to them or if you want to delete them to free up space.

Storage Space

One of the administrator’s day-to-day portal management tasks will involve monitoring and freeing up space used by the various content types, especially document and image libraries. The storage section facilitates this task by offering the Manage Storage Space Allocation link. Navigating to it leads to a similarly named page that allows the portal administrator to view portal site lists, all document libraries, and their documents along with the amount of space that each uses. (See Figure 18-6.)

Figure 18-6.Document Library view on the Storage Space Allocation page

Figure 18-6 shows the Document Library view that helps the administrator quickly identify which document libraries in which areas are responsible for the greatest use of space. The vertical task bar on the left shows the ability to view the list by individual document, which will show an ordered list of all documents across all libraries of the portal areas. There is also the ability to view non-library lists such as Task, Events, and Contact lists in terms of their storage space usage. From there, the administrator can navigate to or delete the listed libraries, documents, or list items to free up space. It will be up to the administrator to ensure that libraries have been backed up before deleting them, as there is no such indication in the provided interface. This could be accomplished by sending an e-mail to the owner of the library as listed in the library’s property pages.

This feature works only at the portal level, meaning that you won’t see Windows SharePoint Services site-based document libraries or lists in this page.

Regional Setting

This last section of the Manage Security And Additional Settings page allows the portal administrator to set the locale, time zone, and time format for the portal site. The reason it is important to set the time zone is that you want the creation or modification timestamp for content to be accurately recorded in the content database. In scenarios where the Web front- end servers reside in a different time zone than the user as well as the content databases, this is crucial. The configuration of the default sort order used when displaying lists chosen as a function of the locale is also important. For example, if the locale is French, the sort order would typically be French as well, which takes into account additional sorting rules related to that language’s additional characters and character modifiers.

Manage Alerts Settings

When users want to be notified via e-mail that a document has changed or that search results for a particular query have changed, they create a SharePoint Portal alert. Because this feature is used at the users’ discretion, administrators might need to manage them to keep users’ alerts under control. The Manage Alerts Settings page exists to help administrators with this task. Figure 18-7 shows this page, which the administrator can access by clicking the like-named link on the General Settings section of the Site Settings page.

Figure 18-7.Alerts management options on the Manage Alerts Settings page

The following list describes each of the settings found on the Manage Alerts Settings page and their usage:

User Alerts Management.

• If a user decides one day that she has created too many alerts and does not want to track down where each was created to cancel each alert, the administrator can delete all the user’s alerts for her by following the Manage User Profiles link. The resulting page will list all users who have subscribed to alerts. By hovering the cursor over a user name in the list and clicking on the drop-down arrow that appears, the administrator can choose to deactivate the user’s alerts temporarily or delete all of them.

    If a user has her Create Alerts right revoked, she will retain her current alerts and receive alert messages for them. If appropriate, use the link described next to eliminate them after revoking permissions.

Delete All Alerts And Alert Results.

• The administrator can follow the Delete All Alerts And Alert Results link, which will ask for confirmation of the action before executing it. This is typically done in environments where it is decided, after deployment, that a given portal site should no longer support alerts. After disabling the feature, deleting all alerts and alert results would prevent any previously created alerts from contributing to the e-mail message queue. See the following note on how to disable the feature.

Delete All Alert Results E-Mail Messages.

• This link is used to clear the portal site’s e-mail queue of any alerts. It comes in handy when the queue has accumulated too many alerts—for example, in situations where the e-mail server to which they were sent has been down for a long time. Clearing the queue would avoid bombarding the users’ mailboxes with all the queued-up alerts. Of course, careful consideration must be given before clearing the queue, as users would not get notified for changes listed in the queue at the time of deletion.

Alert Quotas.

• This group of settings allow the portal administrator to limit the total number of alerts both at the portal level as well as for the users.

Default E-Mail Address For Alerts.

• The portal administrator can use this setting to specify to the alert system which e-mail property in the users’ profiles to use when users create their alerts. Only fields that have been defined as e-mail fields will show in the drop-down selection. You should select the Always Use User Profile Field check box to prevent users from entering another e-mail address.

SMTP Server For E-Mail Alerts.

• The change default e-mail settings link is used if the administrator wants a particular server to use different mail server settings than those defined as default on the Central Portal Administration pages. The settings are defined for a particular virtual server chosen by the administrator and will override the portal-defined default. This is useful in scenarios where a particular server does not have access to the default portal e-mail server based on its location.

Change Portal Site Properties And SharePoint Site Creation Settings

The purpose of following this link is for the portal administrator to change how the portal area pages are displayed to the requesting browsers. There are four customizations that the linked page provides:

Portal Site Name and Description.

• The Name property will affect what is displayed at the top of each area page in the portal site. The Description property is not displayed and is for the administrator’s own use.

Custom Portal Site Logo.

• This setting allows the administrator to designate a different logo file than the default set at install time. Any path relative to the local server is acceptable, but the administrator will have to ensure the logo file has been copied to all Web front-end servers for this to work. To avoid having to do this, a single accessible URL can be defined instead. Keep in mind that this URL can be served in a load-balanced scenario, assuming the logo file is copied to all load-balanced Web servers.

Location For Creating SharePoint Sites.

• If this setting is left blank or if its default value of /_layouts/language/scsignup.aspx is used, any sites created from within the portal site will be created in the default content database. If portal administrators want newly created sites to default to using an alternate content database, they will have to change this property to a URL that points to a Web server running Windows SharePoint Services with Self-Service Site Creation enabled (keeping in mind that the server needs to have a content database defined for it to use on its administration pages). A few additional rules to remember include:

  • The URL must end with /_layouts/language/scsignup.aspx.

  • The URL for creating sites from the Sites Directory is limited to 2048 ASCII characters. In addition, no component of the URL, such as the virtual directory or virtual server, can exceed 128 characters.

  • Leaving the URL blank reverts the value back to /_layouts/language/scsignup.aspx.

Custom Cascading Style Sheet.

• By default, the portal site uses a file called sps.css, which is found in the /_layouts/language code number/styles folder. A Web designer can design an alternate cascading style sheet file to customize the look of the portal pages. To have the portal site use this new .css file, the administrator needs only to place it in a centrally accessible location and specify the URL in this property.

    Avoid editing the sps.css file directly, as it can be overwritten when upgrading or installing a fix or running a repair on the installation from the Add/Remove Programs Control Panel applet. Placing a custom .css file in a centrally accessible URL ensures that it will be available regardless of what happens with the portal server’s installation.

Portal Site Content

The Portal Site Content section of the portal site’s Site Settings page, shown in Figure 18-8, allows the administrator to define additional area pages, change the portal site’s navigational structure, configure the automated association of content links to pertinent area pages with the Topic Assistant, manage the content of portal area targeted links, as well as import data from Microsoft SharePoint Portal Server 2001. Each of these options shows up as a separate link, each of which we will examine next.

Figure 18-8.The Portal Site Content section of the portal site’s Site Settings page

Manage Portal Site Structure

Before embarking on a discussion of how to manage the portal site structure, let’s look at what the portal site is composed of in terms of Web pages and content. The first thing to realize is that each portal site has a home page. This home page can be edited and customized, but it can never be deleted. All other pages in the portal site are referred to as areas or area pages. In SharePoint Portal Server 2003, areas serve two purposes. First, they provide a navigational structure or map of the portal site and related content. By adding, moving, or deleting areas, administrators can change the view of the portal site for users. Second, they provide a centralized structure for storing and organizing content into content-specific areas, which results in giving users a structure for information browsing. Areas direct readers to the information they seek through an organized hierarchy of topics. Areas are intended to provide a flexible way to both describe and find documents as well. By default, the installation creates three top-level areas called News, Topics, and Sites. These can be deleted or modified at will, and additional ones can be created as well. You can think of an area as both a category as well as a team site that will contain content pertinent to that category. In any deployment of SharePoint Portal 2003, the true challenge lies in deciding how to categorize content and organize the navigational structure of the portal site.

One of the main features a portal area page has that a regular team site page does not is its association with the Portal Site Map, which defines the portal site’s navigation structure. Figure 18-9 shows that on the News area page, and on every other area page, there is a horizontal navigation bar of links running along the top of the page as well as a vertical navigation bar along the left side called Current Location. As just mentioned, these navigation bars are automatically updated to reflect the structure defined on the Portal Site Map.

Figure 18-9.The portal site News area page with focus on the navigation bars

When administrators follow the Manage Portal Site Structure link found on the task bar below the Current Location navigation bar, they are taken to the Portal Site Map page, which shows a tree-like view of the area page hierarchy. The top level is, of course, the home page. Any portal areas that fall one level indented below the home page will show up as links on the top navigation bar. Any area pages that are placed at levels below the area in focus will show up on the left-hand vertical navigation bar (assuming that the area has not been excluded from portal site navigation on the Display tab of the Site Settings page for the area). This page allows the administrator to create new portal area pages, manage existing ones, and alter the navigation bars of these pages simply by dragging and dropping the areas to different locations in the tree structure. The Portal Site Map can be seen in Figure 18-10, with the News area node expanded. Notice the relationship between the structure shown on the map and the display of that area page in Figure 18-9.

Figure 18-10.The Portal Site Map

Beyond creating, deleting, and moving area pages to alter the navigational structure of the portal site, the Portal Site Map allows the administrator to edit each area’s properties. This is achieved by hovering the cursor over the area in the Portal Site Map, clicking on the drop-down menu, and selecting Edit. Alternately, as each portal area is viewed, the administrator can click the Change Settings link in the Action menu on the left-hand column to edit the area’s properties as well. This leads to the area’s Change Settings page shown in Figure 18-11. The Change Settings page is composed of the following five categorized tabs of properties:

General.

• This tab allows the administrator to change the title that appears on the area page, its relative URL path name, area description, contact e-mail that will appear on the area page if defined, location in the site structure, as well as creation and modification dates.

Publishing.

• This tab is useful if the administrator wants an area page to appear only as of a certain date and to be automatically removed from the navigation links after the expiration date. Keep in mind that not only are the links unavailable but the page itself (as well as its content) is also no longer available to users.

Page.

• Just as team sites are created from Windows SharePoint Services templates, portal area pages are created from area templates. This tab has two sections. The Subarea Templates section specifies which template should be used for subsequent creations of subareas below the currently selected one. The Area Templates section allows the administrator to change the template of the currently selected area.

Display.

• This tab is used to control whether or not to exclude the area page from the navigation bars, to determine the order in which to place the link on the navigation bars, and to associate a custom image to show on the area page.

Search.

• This tab allows the administrator to set content created in this area to be excluded from search results, as well as to configure whether the Topic Assistant should suggest content links to be published for this area.

  

  Figure 18-11.The Search tab of the Change Settings page of an area

Manage Top-Level Lists and Document Libraries

Following this link takes administrators to the portal site’s Documents And Lists page for the Home area, which allows them to create and view content lists just as any Windows SharePoint Services site. Also, keep in mind that each area that is created has its own set of content lists, as though it was its own team site that could be managed by following the Manage Content link on the left-hand navigation bar under Actions. See Chapter 16 for more details on list and content types.

Manage Targeted Links on My Site

Portal administrators can target content to the personal sites of portal users. Users who click My Site on the navigation bar to view their personal site will see all the content that is targeted to them for the audiences to which they belong through Web Parts, such as the News For You or Links For You Web Parts.

Audiences are defined as users who meet certain criteria. Users are said to be members of an audience if they meet that audience’s membership criteria. Criteria examples defined when an audience is created include a user account’s group membership or a user account’s property, such as Title or Department as stored in the portal profile of the account.

Content is targeted to personal sites by adding listings to the Targeted links on the My Site area or News area, and then editing the display properties of the listings to target specific audiences. Users then see the content that is targeted to them in the Links For You and News For You Web Parts on their personal sites. Content added to the Targeted links on the My Site area is displayed in the Links For You Web Part. Content added to the News area is displayed in the News For You Web Part.

  Portal content administrators can target portal listings such as people, links to portal site or Windows SharePoint Services site content, news, and custom text. To view and manage which listings are targeted, the administrator can select the Portal Listings link on the area’s Documents And Listings page, which is available from the Manage Content link of any area.

Import Microsoft SharePoint Portal Server 2001 Data

This link is used as part of the upgrade procedure when upgrading from Microsoft SharePoint Portal Server 2001. In such a scenario, before installing Microsoft SharePoint Portal 2003, the administrator would first run the upgrade tool provided on the product CD. This tool would create a file called V1Export.XML containing all the data of the original portal. After installing the newer version, the administrator would then navigate to this page and import the data from this file by specifying its path.

Here are some additional notes related to upgrading and importing data from Microsoft SharePoint Portal 2001:

• Some data from SharePoint Portal Server 2001 is imported during upgrade, but it cannot be used in SharePoint Portal Server 2003. This includes portal customization and most SharePoint Portal Server 2001 custom Web Parts.

• To use the document management capabilities of SharePoint Portal Server 2001, you must install the optional components for backward-compatible document libraries.

• Security roles are exported from SharePoint Portal Server 2001 but are not imported to SharePoint Portal Server 2003. You can keep this information as a record to use when deciding how to assign users to site groups.

• After completing an upgrade to SharePoint Portal Server, you will not be able to back up and restore the client components for backward-compatible document libraries.

• The portal content and dashboard folders are not deleted during upgrade and appear in the Documents area of the portal site. After you have migrated all the content from these folders, it is recommended that you delete the folders.

Search Settings And Indexed Content

One of the most powerful features of SharePoint Portal Server 2003 is its search capability. This section of the Site Settings page has six links that allow the administrator to configure all aspects of how search indexes are created, how external content is crawled, and how results are skewed for queries received from users. For details concerning the configuration and management of the search and indexing feature of Microsoft SharePoint Portal 2003, please refer to Chapter 22.

User Profile, Audiences, And Personal Sites

This section of the portal’s Site Settings page, shown in Figure 18-12, allows the portal administrator to configure automatic importing of profiles from Active Directory domains, manage the audience membership recalculation schedule, and manage users’ personal sites for them when the need arises.

Figure 18-12.The User Profile, Audiences, And Personal Sites section of the portal Site Settings page

Manage Profile Database

Each user of the portal site needs to have a profile. A profile consists of a list of properties such as telephone number, address, e-mail, department, and so on. A profile is created for each user the first time the user visits the portal site and successfully authenticates to it, a profile can be precreated manually by the administrator, or it can be automatically created from data imported from Active Directory. Keep in mind that if users edit properties, their edits will be overwritten with the information that is in Active Directory the next time an import is scheduled. The exception to this rule applies to custom fields for which no Active Directory association has been made. Another feature allows the administrator to select which data from a user’s profile properties should appear in the My Site area of that user and, then, can also be modified by that user. To add a profile property, click the Add Profile Property link in this section of the page.

The advantage of populating data into these profiles is that it can be used by the search service to help users find other users. For example, in a large organization, a portal user in one country might need to find the department manager of a division in another country. If the portal profiles have been filled in with meaningful data, the search service will be able to find the person. Clicking on the Manage Profile Database leads to a like- named page with the following links:

Add User Profile.

• This link is used to precreate a profile for a user who has yet to visit the portal site.

View User Profiles.

• This link is used to see a list of existing profiles from which the administrator can view and modify a user’s profile properties.

Configure Profile Import.

• This link is used to define which domain or forest to import the user account data from and automatically create profiles for the user even before he visits the portal site. Part of this configuration requires specifying a service account with read privileges to the domain/forest to be used for gathering the data. Also, a schedule can be defined that dictates how often to check for new users to create their profiles and import their data. There are two types of schedules, full and incremental. Full will re-read and re-import data for users already possessing a profile (effectively overwriting any data that might have been modified by the user or administrator). Incremental will create profiles and import data only for new users discovered since the last full import. Keep in mind that the Profile Import Account needs to have the domain administrator privilege assigned to it for this feature to work.

View Import Log.

• This link is used by the administrator to troubleshoot problems with profile import configuration. Information such as when the last import was attempted and any error details is available here.

At the bottom of the Manage Profile Database page is the User Profile Properties section, which allows the administrator to define additional properties and to edit behaviors of properties. Behaviors include the ability for users to include them in their My Site, edit them, and map them to Active Directory.

Manage Audiences

Audiences allow organizations to target content to users based on their job or task, as defined by their membership in a Windows 2003 security group, distribution list, organizational reporting structure, or the public properties in their user profiles. Audiences are managed centrally across one or more server farms hosting SharePoint Portal Server 2003. They apply across one or more portal sites in a deployment, not to individual areas, sites, or items. Following the Manage Audiences link from the Site Settings page of a portal site takes you to the Manage Audiences page, which is shown in Figure 18-13.

Figure 18-13.Manage Audiences administration page

You must have the Add, Change, or Delete Audiences right to manage audiences. As an audience manager, you can view all members of a specific audience and find the audiences to which a specific user belongs, as well as manage the rules defining audiences and compile audiences as the rules and members of an audience change.

The process for targeting content requires that you first create an audience (unless one already exists that you can use). Then you target an item, such as a document or news listing, to one or more audiences. You can do this at the time you create an item or at a later time. If you didn’t originally create the item in a specific area and if you didn’t specify an audience, you can follow the steps that appear at the end of the chapter to target an item and to store it in an area that uses the Targeted Content Web Part, called Links For You. Finally, audience membership must be compiled either manually or at scheduled intervals.

  Audiences are not used to assign rights and permissions. SharePoint Portal Server uses site groups to assign rights and permissions to users within the portal site. Audiences are used to manage how content is distributed and displayed, not to enforce security. They push information to a user; they do not restrict or permit access to information.

The Create Audience link on the Manage Audiences page allows the administrator to create an audience and define the rules of membership. Rules of membership are always dependent on the property values of a user’s profile matching the criteria defined by the rule. More than one rule can be associated with an audience, along with a definition as to whether all rules must be met or whether only one rule must be met to satisfy audience membership.

Audience membership must be recompiled on a regular schedule to ensure that all new users are added and any users who no longer meet audience rules are removed. This compilation should be scheduled to occur after the profile import schedule has run if it is enabled.

Manage Personal Sites

Each user has a personal site called My Site that she can edit and use for her own purposes. From the bottom of the Site Settings page, the Manage Personal Sites link allows the administrator to specify the location that will store the user’s personal sites and define a default naming convention for the user’s personal site folders that will be created for her by the portal site. This link also allows the administrator to specify which Active Directory or local groups will be made members of the Site Reader group for each personal site as it is created.

By default, the Personal Site Location property is set to personal, meaning that all users’ personal My Sites will be created under the /personal URL of the portal site. The available drop-down box will list managed paths that have been defined for the portal site. It is up to the administrator to decide whether to select a different managed path (which he would have created already) for the storage and servicing of My Sites.

  Managed paths are created on the Define Managed Paths page, which is available from the Virtual Server Settings page of a virtual server. An included managed path is a path for which matching URL requests will be handled by Windows SharePoint Services. An excluded path will be handled by IIS in the traditional manner and not be passed to the Windows SharePoint Services.

The next parameter that needs defining is how to name the folders that will be created for each user’s personal site. There are three conventions to choose from:

User name (do not resolve conflicts).

• Example: https://portal_site/location/username/

User name (resolve conflicts by using domain_username).

• Example: https://portal_site/location/username/ or https://portal_site/location/domain_username/

Domain and user name (will not have conflicts).

• Example: https://portal_site/location/domain_username/

There is no right or wrong method, but the most consistent method in terms of predictability is the third option. Having a predictable name is useful because then you can “guess” the URL to someone’s personal site simply by knowing his name.

The last setting to define for personal sites relates to which users or groups will be automatically assigned the Site Reader site group for each personal site. This will grant them the ability to see the public portion of any user’s personal site. When users add content to their personal sites, they can decide whether that content should be private or public, meaning that anyone in the Site Reader site group can access it. Any local or Active Directory user or group can be assigned.

Another point regarding personal site management is that many administrators also want to know how to get into other users’ personal sites to manage them. Remember that local administrators and SharePoint administrative group members have administrator access to all content, so all that is needed is the URL to the user’s personal site. Having this URL can be useful for allowing the administrator to delete a user’s content to free up space when she uses too much space in her personal sites or to delete the accounts of users who no longer need their personal site.

The preceding information regarding the usefulness of an administrator having users’ URLs is true even for users whose accounts have been deleted. As long as you know the URL to the personal site, you can navigate to it and manage it if you are an administrator.

  Be careful not to delete user accounts until you have cleaned up their personal sites. Despite the fact that you can get into their sites and delete public content, you will not be able to get into their private content. This is because anything marked as private, even private views of portal and team pages, is tied to the security identifier (SID) of the user account. Therefore, only that user account can access private items. If the account is deleted, there is no easy way to get to the content.
So how can an administrator access private items? Simply by running a browser session in the context of the user account in question. Use the Run As option to start a browser session and provide the credential information for the user you want to impersonate within the browser (assuming you can get it or reset the user’s password). Even though you might be logged in at the console as yourself, the browser will act as though the user had logged in as it sends requests to the portal site.

Changing Owners of Portal Sites

What happens when a portal site owner leaves your organization or when you must add a user to or remove a user from a site for which you do not have administrative rights? If you are an administrator on the server and need to change the owner of a portal site to which you do not have administrative access, you can make the change from the Microsoft Office SharePoint Portal Server Central Administration page or from the command line by using the siteowner operation with Stsadm.exe.

  Local server administrators and members of the SharePoint administrators group can perform any task that a portal site administrator can perform for a site collection.

When you create a portal site, you are automatically listed as the site owner. Depending on your configuration, you might also be required to specify a secondary owner for the portal site. Confirmation notifications are automatically sent to the site owner and to the secondary owner, if one exists.

The owner and secondary owner of a portal site are members of the Administrator site group. They are also identified separately in the configuration database as site owners. One can change this owner flag either by using the Manage Site Collection Owners page in SharePoint Portal Server Central Administration or by using the siteowner operation with Stsadm.exe.

  If you remove an owner from the Administrator site group for the site, the owner retains the owner flag in the database and can still perform website administrative tasks.

The SharePoint Portal Server Central Administration page includes a link for managing users for sites. Administrators on the server computer and members of the SharePoint administrators group can use this link to change portal site owners, add users or cross-site groups, remove users or cross-site groups, and change site group membership, all without having to be an administrator on a specific site. Administrators do, however, need to know the URL for the portal site.

To change the owner of a portal site, follow these steps

1. From the home page of the portal site, click Site Settings.

2. On the Site Settings page, in the General Settings section, click Go to SharePoint Portal Server central administration.

3. On the SharePoint Portal Server Central Administration page, in the Security Configuration section, click Manage site collection owners.

4. On the Manage Site Collection Owners page, in the Site URL section, type the URL of the portal site, and then click View. The information for the current site owner and secondary owner appears on the page.

5. In the Site Collection Owner section, type the user name (in the form DOMAIN\username) for the user who will be the site owner and administrator.

6. If you have a new secondary contact name, type the user name in the Secondary Owner section.

7. Click OK.

To change the owner of a portal site by using Stsadm.exe, you must know the URL for the portal site and the specific user name that you want to change. You can use the siteowner operation to change the owner or secondary owner of a portal site.

The syntax for changing the owner of a portal area is:

stsadm.exe -o siteowner -url <url>   [-ownerlogin <DOMAIN\username> | -secondownerlogin <DOMAIN\username>]

Summary

In this chapter, we saw that the portal administrator has many responsibilities and management tasks relating to maintaining a portal site. Each feature the portal site adds to Windows SharePoint Services results in its own management requirements, for which there are administration tools available through the Web-delivered Site Settings page. First, the management of who can access the portal site, the level of access to the portal site, and whether or not anonymous access is allowed can be controlled. Next, management of alerts gives the administrator the ability to control alert usage and helps users clear out alerts when they get out of hand. With the addition of areas and content categorization features, management tools in the form of the Portal Site Map and the Topic Assistant are provided. To help manage the ability to target content to users that meet preset criteria, the administrator can use the audience management links. Finally there are management tools to manage personal sites as well.