Designing the Windows SharePoint Services Environment

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 Sites

Top-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 Sites

The 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:

Shared A Web Part added to a Web Part page by a user who is creating or making changes to the Web Part page in Shared view. Shared Web Parts are available to all users of a Web Part page with appropriate permissions.
Personalized A shared Web Part with one or more property values modified by a user who has made changes to the Web Part in Personal view. The changes made to the personalized Web Part are available only to the user who made those changes. However, other users who did not make changes in Personal view continue to see the shared Web Part.
Private A Web Part that a user has added to a Web Part page from a Web Part gallery or imported from a computer while creating or making changes to the Web Part page in Personal view. Private Web Parts are available only to the user who added or imported the Web Part. No other users can see private Web Parts.

The standard Web Parts available when a top-level website is created are

Announcements Used to share new items with users who have access to the site. By default the view on the home page can show up to five announcements, but custom views can be created. Announcements can be given expiration dates, after which they will no longer appear on the home page but will still exist in the announcements page. Announcements, if used, should be prominently displayed on the home page.
Contacts Used to share contact names, phone numbers, email addresses, and other information on the home page. If you are using Outlook 2003 you can copy contacts from your Outlook address book, or copy a contact from SharePoint to your Outlook address book. The contacts list is a great way to clarify roles and "who does what" in the group, team, or department, and provides a central place to update contact information.
Events Tracks and displays items that have start dates associated with them and can display these items in a calendar format (by day, by week, or by month). Note that the calendar view can easily take up a large portion of the real estate on the home page, so is best placed at the bottom of the screen.
Shared documents A document library Web Part provides a wealth of document management features. The different kinds of library lists that can be created are document libraries, form libraries, and picture libraries. These are discussed in more detail in Chapter 11, "Managing and Using SharePoint Libraries." Often sites will have multiple document libraries, each designed to store documents for different audiences, because a document library can have only one group of security settings for all its content. You can't create a folder within a document library and assign different permissions to it. Form libraries require InfoPath 2003 to fully utilize, whereas picture libraries are specifically designed for graphics files.
Links Used for posting hyperlinks to web pages of interest to the group using the site. These links can be to external websites or other SharePoint 2003 sites and pages, or even to an individual item, such as a form or image, stored in a library.
Content editor A helpful Web Part for adding text, tables, images, and hyperlinks to the home page. There are three options for entering content: rich text editor, source editor, and content link.
Form Can be used as is to connect to and filter a column of data in another Web Part. For example, if it is linked to a contacts list, when a last name is entered in the form Web Part, the contacts list will show any matching last names. The code can be modified to change the functionality of the form Web Part.
General discussion A general discussion board tracks discussion topics and responses that can be displayed in flat or threaded views. Discussion boards can be helpful in tracking communications that involve multiple people and offer a collaboration alternative to email.
Image Allows you to add a picture or graphic to a web page. An image Web Part can also link to another Web Part that contains a link to a graphic image. So an image Web Part could link to a contacts list if each contact had a link to a photo, and when a user selected a specific contact, his photo would be shown. Figure 5.4 provides an example of this functionality.
Figure 5.4. Image Web Part linked to a contacts list.
Members Shows all users or groups who have access to the current site. Clicking on the name of the member takes you to the public view of the user's personal site or user information if the user doesn't have a personal site.
Page viewer Used to display a web page, file, or folder on a Web Part page. In Figure 5.5 a .jpg file stored in a document library on the ProServices site is displayed in the page viewer Web Part. Note that a slider bar is made available so that a user can scroll the image.
Figure 5.5. Page viewer Web Part showing a .jpg file.
Tasks list Used to assign a task to a member of the team, specify a due date and priority, and indicate its status and progress. Tasks do not link to Outlook 2003 but are viewable from an Office 2003 application via the Shared Workspace task pane, when a document stored in a library on the site is opened.
Issues list Is similar to a task list and is designed to track items, prioritize them, and follow the progress of issues from start to finish. An interesting feature of the issues list is the ability to turn on email notifications, so a user receives an email when she is assigned a task.
XML Web Part Used to display Extensible Markup Language (XML) and apply Extensible Stylesheet Language Transformations (XSLT) to the XML before the content is displayed. Content can be added by XML and XSL editors, or XML and XSL links.

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 Lists

If 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 Collection

Proper 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

Guest Can be granted limited rights to view pages and specific page elements without rights to view the entire site. Users given access to lists or document libraries via per-list permissions are automatically added to the Guest site group. You cannot customize or delete the Guest site group.
Reader Can view items, view pages, and create a top-level website using the Self-Service Site Creation feature if it is enabled. Readers can only view pages on a SharePoint site; they cannot add content. This group is well suited for providing cross-departmental access to SharePoint 2003 site collections, as well as for limiting the damage an untrained user can do to a site.
Contributor This group has Reader rights as well as rights to add, edit, and delete items; browse directories; manage personal views; add, remove, or update personal Web Parts; and create cross-site groups. Members of the Contributor site group cannot create lists or document libraries, but they can add content to existing lists and document libraries. This is the standard group that a user who needs to participate actively in a site collection is given.
Web Designer Has Contributor rights and rights to cancel check-out, manage lists, add and customize pages, define and apply themes and borders, and apply style sheets. Members of the Web Designer site group can modify the structure of the site and create lists or document libraries. This group is not used all that often, except in more complex environments. Typically, a user who is expected to be interacting with a site collection at this level is granted administrator rights.
Administrator Has all rights from other site groups and rights to manage site groups, manage list permissions, create SharePoint sites, and view usage analysis data. The Administrator site group cannot be customized or deleted, and there must always be at least one member of the Administrator site group. Members of the Administrator site group always have access to, or can grant themselves access to, any item in the website. Be wary of making too many users members of the Administrator group because it can be difficult to control the layout and growth of the site collections ("too many cooks spoil the broth").

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.

Table 5.2. Web Part Page and Web Part Rights
Right	Reader	Contributor	Web Designer	Administrator
View Pages	Granted	Granted	Granted	Granted
View Items	Granted	Granted	Granted	Granted
Add/Remove Private Web Parts	Denied	Granted	Granted	Granted
Update Personal Web Parts	Denied	Granted	Granted	Granted
Add Items	Denied	Granted	Granted	Granted
Edit Items	Denied	Granted	Granted	Granted
Delete Items	Denied	Granted	Granted	Granted
Add and Customize Pages	Denied	Denied	Granted	Granted

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 Roles

The 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:

Site collection administrator These are similar to members of the Administrator site group in that they have full rights to all sites in the site collection. A member of the Administrator site group of a subsite can control settings and features only for that subsite and any subsites below it that inherit permissions when they are created. If unique permissions are used, only the site collection administrator can perform these functions.
Site collection owner When a user creates a site, a user is listed as the site collection owner. This individual is added to the list of site collection administrators.
Secondary site collection owner Optionally, a secondary site collection owner can be specified. Adding a user in this role also adds her to the list of site collection administrators.

Additional Decisions to Make for Site Collections

Some additional decisions should be made during the design process for site collections:

Will there be a quota for any or all of the sites? Setting a quota limit for storage sets two values: a warning value and a maximum value. When a site passes the warning limit, an email message is sent daily to the site administrator and owner notifying them that their site is near its storage quota, until the level drops below the warning level. When a site hits the maximum limit, another email message is sent to the owner and administrator, and no new content can be added to the site.
When subsites are created will they use the same security settings as the parent site or use unique settings? This decision needs to be made each time a subsite is created, and the answer may depend on the purpose of the subsite and whether the information contained in it will be confidential or is to be shared with the user community.
Will the top-level website be connected to a portal (assuming that there is one) to include the contents in portal searches, allow connectivity to user profiles, and provide the ability to categorize lists?
Which site groups will have rights to create subsites, document workspaces, and meeting workspaces?
Will anonymous access be allowed to any of the top-level or subsites? Will access be allowed to all authenticated network users, and, if so, what site group will they belong to?
Will access requests be allowed, and, if so, who receives the requests? This is important because if a user can't access a site, he will have the option to send an email to a designated person if access requests are allowed. Otherwise, the user will have to take the initiative to find someone to help him out.
Does site usage data need to be collected? If so, usage analysis processing needs to be configured. This is a quick process and generates useful information about who is accessing which sites, and on what days.
Will document versioning be used, and, if so, what will the standard be for the number of versions of a document to be saved? If it is used, it can dramatically affect the size of the database.
Will any metadata be attached to documents when they are added to libraries? Each site collection administrator can create metadata as needed, but bear in mind that if the metadata differs between document libraries, when documents are moved from one library to another the metadata will be lost, so standards are helpful.
Will anonymous access be allowed in the site collection, and will users authenticated to the domain be allowed access?
Which specific file types need to be blocked from upload to site collections?

Using Site Templates

The 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

The lists within a site
Any Web Part pages within a site
Any custom pages within a site
The theme or borders applied to a site
Any customizations to the Quick Launch bar

Optionally, list and document library contents can be included in the template. Note, however, that site templates do not include the following items:

Security settings, such as a list of users or groups with permissions to the site from which the template was created
Personalizations to Web Part pages
Web discussions from the original site
Alerts from the original site
Web Part assemblies added to the original site

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 Definitions

Another 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.