The differences between Windows SharePoint Services and SharePoint Portal Server 2003 have been discussed previously in this book, along with pros and cons of the different options, so these differences will not be addressed again at this point. If the organization has chosen to implement Windows SharePoint Services the following sections will apply. If the organization is implementing SharePoint Portal Server 2003 the sections on Windows SharePoint Services design considerations are still valuable because the site collections in SharePoint Portal Server 2003 are created by Windows SharePoint Services. Defining the Top-Level SitesTop-level sites play an important role in both Windows SharePoint Services and SharePoint Portal Server 2003. Top-level sites are typically created for departments, divisions, or teams and can have multiple subsites, and subsites themselves can have multiple subsites, down as many levels as the users need. The entire structure of a top-level website and all its subsites is called a website collection. Figure 5.3 provides an illustration of two top-level websites in Windows SharePoint Services, Site1 and Site2, and shows possible URLs for these sites and for their subsites. Figure 5.3. Top-level sites in Windows SharePoint Services.A member of the sales department could use the sales department top-level website to access departmental announcements, the departmental calendar, or a list of contacts or URLs, as well as access one or more document libraries or other lists. There may be different subsites as well, created for specific teams or divisions of the sales department, that can have their own security settings, which affect who can access the subsites and the information contained within them. Note that Windows SharePoint Services site collections can be linked to a portal site at a later time, which provides an upgrade path to organizations that want to start with a less costly implementation of SharePoint 2003 and potentially grow in the future. Or the site collections can be migrated directly to a SharePoint Portal Server 2003 portal site. TIP Titles given to the SharePoint 2003 top-level sites, subsites, workspaces, libraries, and lists should be descriptive to aid in efficient navigation. A best practice is to change the default names of libraries and lists to start with the name of the site that houses them (for example, Announce ments could be changed to Safety Dept Announcements). This helps the users to quickly see what site they are in when accessing the library or list through a shortcut, provides more useful information in the History pane, and makes shortcuts added to Favorites in Internet Explorer more recognizable. When the Portal Search feature is used, the hits that come up will also be more instantly recognizable. Choosing Web Parts for the SitesThe typical user will spend most of his time within the site collections that contain the information he accesses on a daily basis, so determining the most useful components of these sites and securing the information so that each user has the appropriate access is important. When a top-level site or subsite is created, it contains the Web Parts in the template that was chosen. One of the standard templates can be used, or the organization can create and fine-tune templates during the testing process. There are three different kinds of Web Parts, which is an important distinction to discuss when designing the standard template for top-level websites or subsites:
The standard Web Parts available when a top-level website is created are
A good exercise is to create a table that lists which of these standard Web Parts each top-level website will use and to confirm these selections through the testing process. Typically, a top-level departmental website should have no more than a dozen of these on the home page, or the page can become cluttered, and subsites should be used. TIP Spend time to run the different Web Parts through their paces, especially the ones that will receive the most use, such as document libraries, announcements, events, and others that the goals of the project require. This gives users a chance to determine whether their document management and collaboration requirements can be met by SharePoint 2003 out of the box, or whether third-party add-ons and customization are required. For example, SharePoint document libraries do not offer an undelete function out of the box either, but solutions are available to make this function available. Creating Custom ListsIf the organization has requirements that aren't met by the standard Web Parts, custom lists can be created in a number of ways by choosing the Custom List option from the Create page. The custom list allows the creator to select the columns that will be a part of the list and determine what the content of each column will be to suit a variety of different purposes. A helpful way to understand custom lists is to compare each one to a spreadsheet in terms of their use. Figure 5.6 shows a custom list designed to track customer satisfaction ratings. The first column was renamed "Customer Name" from "Title," and the other columns were added. "Project Name" can hold text, up to 100 characters, whereas "Start Date" and "End Date" can hold dates, and "Technical Sat," "Soft Skills Sat," and "Deliverables Sat" can hold numbers from 1 to 100 that are expressed as percentages. Note that the second line item has a paper clip icon next to it, which indicates that a document has been uploaded as an attachment to this line item. Figure 5.6. Sample custom list.Crafting the Appropriate Groups and Security Settings for the Site CollectionProper attention should be given to designing a workable set of site groups for the SharePoint 2003 implementation. In Windows SharePoint Services, each user must be a member of at least one site group to view or access a SharePoint site. Each site group has certain rights that are assigned by default and can be modified by administrators. Additional site groups can be created and shared within the site collection, or most unused site groups can be deleted. Because SharePoint 2003 is tightly connected to Active Directory, a site administrator can simply use AD security groups or distribution lists when populating site groups, or new groups may need to be created in AD based on SharePoint 2003 access requirements. For example, a group Sales may already exist in Active Directory, but during the design process it is determined that this is not granular enough, and new groups Sales Manage ment, Sales Staff, and Sales Administration are created. When the portal is created, all these groups are added to the Reader site group for the portal but then given different rights to the Sales site collection: The Sales Management group is assigned to the Administrator site group, the Sales Staff group is assigned to the Contributor site group, and the Sales Administration group is assigned to the Reader site group and given per-list rights to certain Web Parts as required. TIP It is much easier in most cases to create domain groups that are granular enough to use when providing access to SharePoint 2003 sites than to add individual users and try to manage their individual rights. This does require coordination between the SharePoint 2003 administrators and the domain administrators but will facilitate site management later. The predefined site groups are
TIP Use the Reader group for new users who haven't received much or any training to allow them time to get used to the new environment and browse the different Web Parts but not have the ability to make changes or additions. Then selectively give them Contributor rights to the Web Parts that they have the most need to use, such as a discussion board or a document library, which register as Guest privileges for the top-level site. Figure 5.7 shows an example of an AD group being added, as well as an individual being added by his email address. Figure 5.7. Adding a domain group and a user to a site group.Figure 5.8 shows an example of how the different site groups can be composed of different users and groups. It can be helpful to document these decisions in a similar way during the design process because it can get confusing remembering where AD groups are being used, as opposed to individual users or cross-site groups. Note that administrators on the local server have full administrative rights to site collections. Figure 5.8. Site group composition.Table 5.2 summarizes the Web Part page and Web Part rights granted by default to each site group. This is helpful information to have when deciding which site groups to use when providing access to site collections. Note that the Reader site group is denied a number of rights, such as adding or removing private Web Parts, and prevented from adding or editing items. The Contributor site group gets a number of privileges that may be excessive for the particular site collection, and the administrators may make the decision to limit the rights of the Contributor group or to create a customized site group with customized rights.
It is worth pointing out that these privileges can be changed if needed. Figure 5.9 shows part of the Edit Site Group page for the Contributor group for the ProServices site collection. The administrator for this site may not want members of the Contributor group to be able to delete items, and so would uncheck the box next to Delete Items and then save the change, which would immediately become active for that group. Figure 5.9. Edit Site group page.For more specific needs, new groups can be created using the Add a Site Group option on the Manage Site Groups page. Or, if a new group is needed that is to be used on other sites within the site collection, a cross-site group can be created. An owner can be assigned who can control who can be added or removed from the cross-site group, or the cross-site group can be set up so that the members of the group can add or remove users. Defining the Site Management RolesThe design team needs to put some thought into selecting the individuals who will fill the different management roles required to manage the site collections. A best practice is to have at least two employees in the SharePoint Administrator group in case one is not available during an emergency situation. The following is a list of key administrative roles that need to be determined during the design phase:
Additional Decisions to Make for Site CollectionsSome additional decisions should be made during the design process for site collections:
Using Site TemplatesThe prototype testing phase is an ideal time to create a generic site template that the stakeholders can agree on as offering the basic features and layout that can serve as a starting point for each departmental or team top-level website. This template can then be used instead of one of the generic templates that Windows SharePoint Services offers, which can save a tremendous amount of time for each site collection administrator. A site template is a file with the .stp extension that includes all the design information about the site, including
Optionally, list and document library contents can be included in the template. Note, however, that site templates do not include the following items:
One clarification to make here is that the site template is saved within the site collection gallery, so it is not available from the portal when a new site collection is being created. Some command-line work is required to "feed" the template to the portal. See the SharePoint Portal Server 2003 Administrator's Guide, and search for "Managing the Central Template Gallery." The process involves saving the site template to a drive on the SharePoint server and then using the stsadm.exe tool, and the addtemplate function. When completed, IIS needs to be restarted for the change to take effect. Using Site DefinitionsAnother option is available to site templates, and that is a site definition template. This process involves actually editing .xml files and should be considered a more advanced process than working with site templates. Every site definition is stored in a folder on the file system of each front-end web server and includes at minimum an Onet.xml file. Administrators of the server computer can create custom versions of the default set of site definitions. It is generally recommended that you create a new site definition instead of editing an existing site definition file. The Webtemp.xml file also needs to be modified to include the new site definition. Figure 5.10 shows a portion of the Webtemp.xml file, with a site definition template circled, and with a smaller circle pointing out the attribute Hidden="False". So a server administrator can actually hide site definition templates by changing this to Hidden="True" if she doesn't want to make it available to individuals with the rights to create sites or site collections. Figure 5.10. Sample Webtemp.xml file. |