Chapter 4. Planning the SharePoint 2007 User Environment

IN THIS CHAPTER

Whereas Chapter 2, “Planning and Architecting a SharePoint 2007 Deployment,” and Chapter 3, “Planning Redundancy and Scaling the SharePoint Environment,” covered the high-level principles and decisions that need to be made when implementing the hardware and software to best meet an organization’s needs, this chapter turns to the needs of the end users, which must also be examined in depth.

Many IT projects can essentially exclude the user community because they are fundamentally infrastructure projects that won’t affect the end users’ day-to-day experiences with the network. For example, a server operating system upgrade will have minimal impact on the end users, assuming it goes well. A new virtual private network solution will require that end users receive some training. A change from one email platform to another—for example GroupWise to Exchange—will require some additional planning and will definitely need more training, but the end users will have little say in the look and feel of the end result because there are relatively few options. The user community might request certain features, such as Outlook Web Access, public folders, and instant messaging integration, but the basic functionality offered by the Outlook client is fairly static.

Implementing a SharePoint 2007 solution, on the other hand, must involve the user community to a greater degree than standard IT projects, or the end users might simply choose not to use it. Of course, if end users are forced to use it (for example the intranet “goes away” to be replaced by SharePoint 2007) the project might not be an official failure, but unless different departmental managers, specialists in different key areas, and power users are involved in the process, the chances of SharePoint 2007’s features being fully utilized are reduced.

Key Components of the User Environment Design Process

Because not every end user will be involved in the design process, the stakeholders have to dedicate time and effort to discussing, documenting, and then building the environment that meets the immediate needs of the user community and is then scalable to meet their needs in the foreseeable future. This section concentrates on the processes involved in designing the user environment to ensure that the software configuration meets the needs of the end users after the hardware is configured and in place. It is therefore important to get key end users involved in the building, configuring, and testing processes, to document key goals, and to adjust the design to keep their needs in mind.

Prioritizing the Goals for the Design of the SharePoint 2007 Environment

Along with the architectural goals for the SharePoint 2007 implementation, the organization will have goals more specific to the needs of the end users. These goals might include document management needs, collaboration needs, workflow needs, language requirements, publishing needs, and access to key performance indicators and dashboards. It is important to document the goals of different levels of users prior to configuring SharePoint 2007 to ensure that the project is successful, and to identify which are the “must haves” and which are the “nice to haves.”

Most organizations have a combination of existing technologies, practices, business requirements, and pain points that add up to a list of requirements for the SharePoint 2007 project. A few meetings with key stakeholders can generally flesh out the key goals for the project, along with the basic timeline and possibly even some budgetary constraints.

Tip

Creating a spreadsheet of end user requests for functionality for the SharePoint 2007 implementation project can be very helpful. The users making specific requests can be listed, as can the benefits of the feature being available, and the phase of the project when the feature will be implemented. If possible, measurable criteria should be listed for each goal, or else it will be difficult to tell that a goal has been met. Rather than defining a goal of “implementing workflow,” pursue a goal of “implementing workflow to facilitate the review of controlled documents in the Quality Assurance department.”

Identify the Key Users

Part of the process of identifying the goals for the SharePoint 2007 implementation will include determining who the key users are. These users will perform the brainstorming to launch the project, determine the scope of work, timelines, and resources required. Key members also will sign off on the different phases and make adjustments to the scope as needed.

At a minimum, the following individuals should be involved in the initial discussions:

  • IT managers (CIO, director[s], web services, operations)
  • Security resources
  • Human resources manager
  • Sales managers, directors
  • Marketing managers, directors
  • Project management office managers, key project leads
  • Help desk managers

Additionally, the following users might be good to involve from the beginning if they are key proponents of the project:

  • Web designers
  • Key power users
  • Top salespeople and “road warriors”
  • Key partners, if the SharePoint 2007 environment is being implemented to enhance intercompany collaboration
  • Auditors if the SharePoint 2007 environment will be subject to Sarbanes Oxley scrutiny, FDA regulation, or other governance
  • Members of the Information Technology Infrastructure Library team

Roles should also be assigned to each participant in the project. Certain members will be approvers, whereas others will perform the testing and configuration, and others will act as testers during the pilot and/or prototype testing phases.

Documenting the Design Decisions

Documentation should be created that summarizes the findings and decisions made in the design process. These decisions can then be implemented in the test environment where end users and testing resources can be called on to run the configuration through its paces to confirm that the configuration meets their expectations and requirements.

Several key documents include the following:

  • End user/Functional design document: This is different from an architectural design document because it details the inclusion and configuration of elements that will affect the day-to-day experience of end users, and what features and tools are available. For example, how many web applications will host site collections, and which templates will be used, whether personal sites be offered, and whether presence information be provided has to be documented. This chapter includes an overview of key design decisions that need to be made and ideally documented.
  • Testing document: Testing should be planned to ensure that the users are involved in the proof of concept or prototyping process. Key elements such as top-level site design, navigation standards on sites, publishing site look and feel, appropriate top-level sites, and inclusion of the new Blog and Wiki web parts should be thoroughly tested. Integration with Office applications should also be tested, especially if different versions of Office are in use. Similarly, all different operating systems, including Apple and Linux systems, and different standard browsers should be tested.
  • Implementation plan: This plan essentially takes over when the hardware is configured and SharePoint is installed. It should cover the length and resources involved in the proof of concept, and implementation or migration phases. Because of the complexity of the SharePoint 2007 family, many organizations choose to implement only a subset of features initially, and then enable additional features after several months, when users are familiar with the basic features.
  • Training plan: Training is especially important for users with no SharePoint experience, and in implementations providing the full set of SharePoint 2007 tools to the user community. There are typically a number of elements that can be used, from the help tools included with the software, to customized training documents, classroom trainings, and proctored lab sessions, and these should be offered for end users as well as site administrators.

Designing the Windows SharePoint Services Environment

If the implementation includes only Windows SharePoint Services 3.0, the design process will be simpler than if it involves SharePoint Server 2007. The previous three chapters have outlined the differences between Windows SharePoint Services 3.0 and SharePoint Server 2007, so this section assumes that Windows SharePoint Services 3.0 has been selected, and the hardware and software design decisions have been made.

Some high-level questions that should be addressed when designing the user environment for Windows SharePoint Services 3.0 include the following:

  • The number of site collections needed: Site collections can be on different servers if needed. Multiple site collections complicate administration, but are often necessary to split data across multiple content stores.
  • Configuration options: How will each site collection be configured in terms of the many options available in areas such as users and permissions, libraries and lists to include, blocked file types, and maximum file upload sizes?
  • Defining the look and feel of the site: Custom site definitions can be created, different site themes can be used, master pages can be modified to meet the specific needs of the site collection users, different site templates can be offered, and web parts can be made available in one but not the other.
  • Will functionality such as RSS (Really Simple Syndication) feeds and blogs be enabled?
  • What Active Directory (AD) groups, if any, will be used, and are any changes needed to the default SharePoint groups?
  • Additional design options are covered in the next section.

Design Options for Site Collections

A limited, but useful, array of template options is provided in Windows SharePoint Services 3.0. These are discussed in more detail in Chapter 9, “Designing and Managing Pages, Workspaces, and Sites in SharePoint 2007,” but the options are summarized here:

  • Team Site
  • Blank Site
  • Document Workspace
  • Wiki Site
  • Blog Site
  • Basic Meeting Workspace
  • Blank Meeting Workspace
  • Decision Meeting Workspace
  • Social Meeting Workspace
  • Multipage Meeting Workspace

Typically the Team Site or Blank Site templates are used, but there might be situations in which multiple web applications are created and used for different purposes. A general best practice is to keep the environment simple to begin with, and avoid having to work with multiple IIS (Internet Information Services) websites (web applications), manage different ports for these sites, use host headers, or other ways of facilitating end users access to the different web applications.

Pros and Cons of Multiple Web Applications

A benefit of multiple web applications on the same server is granularity of management and separation of databases. Each web application will have its own content database created by default, which can have a variety of advantages for reporting, monitoring, and back up and restore processes. Each site collection can have different site collection administrators, and the features available on the Site Settings page (_layouts/settings.aspx) can be completely different from one site collection to the other. Figure 4.1 provides a snapshot of the Site Settings page. Some examples include the following:

  • Users and Permissions: Individual users can be members of different SharePoint groups, or different AD groups can have access in one site collection, but no access to another.
  • Look and Feel: Different site themes can be used, master pages can be modified to meet the specific needs of the site collection users, different site templates can be offered, and web parts can be made available in one but not the other.
  • The galleries that live at the top level can be different between site collections and have completely different contents.
  • Regional settings can be different: The locale for one site collection can be set to English, whereas another can be set to Dutch (Netherlands), and the date formats reflect this difference of locale.
  • RSS feeds can be turned off for the site collection.
  • The site collection can be excluded from search results, which could protect critical data.
  • Different site collections can connect to different portals.

Figure 4.1. Site Settings page.

image

These settings can be configured by a user with Site Owner permissions.

In addition, some organizations have specific reasons that site collections are on separate physical servers and even in different domains. Some organizations prefer to physically separate different types of data (regulated documents from everyday work product) or different types of users (internal users from external users).

Application Management Configuration Decisions

The next step in the design process, after making the decision of how many web applications are needed, is to better define how each will be configured. This section gives an overview of some of the decisions that need to be made for each web application through the Application Management tab in the Central Administrator console. The following are several items that should be addressed during the design process:

  • Default time zone: Note that this is different from locale, which is set in the Site Settings page for the top-level site in the site collection.
  • Use of quota templates: Will quota templates be used? If so, what will the storage limit be, and at what value below this amount will a warning email be sent? (/_admin/ManageQuotaTemplate.aspx)
  • Person name smart tag and presence settings: Will these be enabled? (_admin/vsgeneralsettings.aspx)
  • Blocked file types: Part of the design and testing process should include a review of the standard blocked file types to see whether this list needs to be changed. For example, .bat files are blocked by default, but the design team might poll users and find out that many .bat files need to be stored and managed on SharePoint 2007. (_admin/BlockedFileType.aspx)
  • Maximum upload size: This can have a dramatic effect on the size of the content database(s) for the site collection, especially if versioning is used for these larger documents. A general recommendation is to keep the 50MB default and then increase it if end user requests justify the increase. Larger files not only take up more space in the database, but take more resources to index, and take up more space on local computers if saved locally or synchronized to Outlook 2007. (_admin/vsgeneralsettings.aspx)
  • Alerts: On for the server or off? If on, is there a maximum number allowed for a user? The default is 500 per user, but many organizations choose to be more restrictive (for example, 100 per user) to keep the overall level of email traffic to a reasonable level, and so that users are more open to other options, such as using RSS feeds. (_admin/vsgeneralsettings.aspx)
  • RSS feeds: Enabled or not? These can also be enabled in the top-level site settings for a site collection. (_admin/vsgeneralsettings.aspx)
  • Blog API: Enabled or not? Will the username and password be accepted from the API or from the currently configured authentication method? Some organizations choose not to allow the use of custom blogs with the blog API because they can be difficult to oversee in terms of content and can be seen as encouraging “venting” or non-business–related communications. Of course, many organizations embrace the use of blogs by some or all employees. (_admin/vsgeneralsettings.aspx)
  • Web page security validation: On or off? If on, when does the validation expire, in minutes, or does it not expire? The default is 30 minutes. Generally this is a good time limit, but some organizations choose a larger number. For example, if an organization requires extensive entry of metadata or uses lengthy surveys, 60 minutes might be a better choice. This allows a user to start an entry, get distracted by one thing or another, and not have the session expire. (_admin/vsgeneralsettings.aspx)
  • Change log: How long are entries kept in the change log before they are deleted? The default is 15 days. Or they might never be deleted. Disk space limitations might encourage shorter amounts of time, whereas regulatory and administrative requirements could require longer amounts of time. (_admin/vsgeneralsettings.aspx)
  • Recycle Bins: Are they on or off for the web application? And after what number of days of storage are items deleted (if ever)? Additionally, is the second-stage Recycle Bin on or off? If on, what percent of the live site quota is allocated to it? (_admin/vsgeneralsettings.aspx)
  • Content databases: How many content databases are required? The default is a single one, but for organizations with a large amount of data (more than 25GB) it might make sense to create additional content databases. If additional databases are to be created, what will the naming convention be? Will Windows authentication or SQL authentication be used? If there will be multiple content databases and there will be multiple Windows SharePoint Services search servers, different search servers can associate with the databases. Finally, what is the number of sites that can be created before a warning event is generated, and what is the maximum number of sites that can be created in the database? The default numbers of 9,000/15,000 are excessive for most environments, so smaller numbers might be selected and can be useful in letting the site collection administrator know that a certain milestone of sites has been reached, such as 100. This could then trigger the creation of a new content database to facilitate management or disaster recovery. (_admin/newcntdb.aspx)
  • Security for web part pages: Can users create connections between web parts? Connection between web parts can slow down performance, and might pose a security risk. (_admin/SPSecuritySettings.aspx)
  • Online web part gallery: Can users access the online web part gallery? Should the organization prevent users from accessing the online web part gallery, which is by default a Microsoft-managed site? (_admin/SPSecuritySettings.aspx)
  • Self-service site creation: Off by default, if turned on, an announcement is added to the top-level site that will allow the user to access the _layouts/scsignup.aspx page shown in Figure 4.2. A secondary contact can be required if needed. This adds a field to the creation form where additional site collection administrators can be added. (_admin/ConfigSSC.aspx)

Figure 4.2. Self-Service Site Creation page.

image

  • User permissions for web application: Do the default list permissions, site permissions, or personal permissions need to be modified? They are all active by default. An organization might want to not allow users to manage personal views, or add/remove personal web parts, for example. In general, a best practice is to not modify these settings unless it is done for a very specific reason. (_admin/vsmask.aspx)
  • Policy for web application: A policy can be created for a specific set of users that allows Full Control, Full Read, Deny Write, or Deny All permissions. This is useful to deny a specific group access to a specific web application. (_admin/policy.aspx)
  • Edit authentication providers: The _admin/authenticationproviders.aspx page allows the administrator to modify the authentication type (Windows, forms, web single sign on), to enable anonymous access, and allows a choice between Integrated Windows authentication (Negotiate [Kerberos] or NTLM) and Basic authentication. Finally, client integration can be enabled or disabled. If it is disabled, client applications won’t be launched. So, for example, the Edit menu in a document library will no longer have the Edit in Microsoft Office Word tool.
  • Workflow settings: User-defined workflows can be enabled or disabled for the web application. In addition, internal users who do not have site access can be alerted if they are assigned a workflow task (generally a good idea, and on by default), and external users can be sent a copy of the document allowing them to participate. This second setting might be more problematic depending on the confidentiality of the documents involved. (_admin/workflowAdmin.aspx)
  • Site use confirmation and deletion: Email notifications can be sent to owners of unused site collections after a certain number of days (90 is the default). The frequency of checks can be set to daily, weekly, or monthly, and to run at a specific time. Finally, site collections can be automatically deleted after a certain number of notices are sent. The default number of notices is 28. (_admin/DeleteSiteConfig.aspx)
  • Connection to Records Center: If a SharePoint 2007 Records Center exists, it can be specified on the _admin/OfficialFileAdmin.aspx page. Chapter 12, “Implementing Records Management and Enabling Web Content Management in SharePoint 2007,” provides additional information on this topic.
  • HTML viewer: First HTML viewing needs to be allowed, and then a path to the HTML viewer needs to be provided, a maximum cache size specified, a maximum file size specified, and a timeout length in seconds decided on.
  • Document conversions: These can be configured for each site collection, and a load-balancing server can be specified and additional details for the conversions specified. Chapter 12 provides additional information on this topic.

Planning Groups and Security Settings for Windows SharePoint Services 3.0

Microsoft provides a limited number of groups that are available by default with Windows SharePoint Services v3. These groups are as follows:

  • Farm Administrators: These users or accounts are defined in the Central Administration from the Operations tab. Members of this group have full access to all settings in the farm. The account used to install Windows SharePoint Services 3.0 will be part of this group automatically as well as the BuiltinAdministrators group, which contains members of the local administrators group on the server. Other groups or users can, of course, be added. A general best practice is to limit the number of users with farm administration rights. This can involve removing the BuiltinAdministrators group because in larger network environments there might be a large number of accounts in this group that need administrator access and control over the server, but should not have administrative rights over Windows SharePoint Services 3.0. In addition, administrator accounts should be used rather than personal accounts.

Tip

Create an Active Directory group called SharePointAdmins and then add that group to the Farm Administrators group in Windows SharePoint Services. Make sure to use administrative accounts in the AD group rather than personal accounts. Instead of giving rights to the jsmith user account, use the adminjsmith account. This facilitates the auditing process when verifying that only administrative accounts are using the Central Administration tools, and makes maintenance of the AD and SharePoint groups easier. If someone doesn’t have an administrative account in AD, they should not be added to an administrator-level group in SharePoint.

  • For each site collection created from the Central Administrator console on the Create Site Collection page (_admin/createsite.aspx), a primary site collection administrator needs to be specified with the option to specify a secondary site administrator. Because these might well be departmental managers, web designers, team leads, project managers, or other resources who will most likely not have a network-level administrator account, regular user accounts can be used. AD security groups or distribution lists cannot be used.
  • If a site is created from a top-level site in Windows SharePoint Services 3.0 (_layouts/newsbweb.aspx page) and the Use Same Permissions as Parent Site option is selected, no site owner needs to be selected because this will be inherited from the parent.
  • If a site is created from a top-level site in Windows SharePoint Services 3.0 (_layouts/newsbweb.aspx page) and the Use Unique Permissions option is selected, Owners need to be defined. Owners of a subsite can be individual users or AD security groups.
  • The default site groups provided in Windows SharePoint Services 3.0 are sitename Members, sitename Visitors, and sitename Owners. This makes the administration process easy because the Members group has Contribute permissions, the Owners group has Full Control permissions, and the Visitors group has Read permissions. Figure 4.3 provides an overview of these different groups, and includes the Anonymous Users group, as well as each List Permission, Site Permission, and Personal Permission given each group.

Figure 4.3. Table of Windows SharePoint Services 3.0 groups and privileges.

image

Designing the SharePoint Server 2007 Environment

SharePoint Server 2007 adds another layer of functionality to the design process. This section outlines some additional areas that need to be considered when configuring the user environment. A main consideration, as with Windows SharePoint Services 3.0, is the number of site collections that will be created. SharePoint Server 2007 is designed with additional management tools, including Shared Services, which facilitate the creation of more complex environments. Because SharePoint Server 2007 offers additional features over and above Windows SharePoint Services 3.0, there is more potential for complex, multisite collection, multiserver environments. This section walks through some additional areas that need to be considered during the design process when SharePoint Server 2007 is being used.

Choosing the Right Site Template

The templates offered for site collections in SharePoint Server 2007 are more numerous than with Windows SharePoint Services 3.0. They include all the templates offered in Windows SharePoint Services 3.0 as well as several additional templates:

  • Document Center
  • Records Center
  • Site Directory
  • Search Center with Tabs
  • My Site Host
  • Search Center
  • Collaboration Portal
  • Report Center
  • Publishing Portal

In general, the Collaboration Portal makes the most sense for a standard site collection, and will remind people with SharePoint 2003 experience of the standard Portal environment that was created by default in SharePoint Portal Server 2003. The standard components of the Collaboration Portal are a home page, a News site, a Site Directory, a Document Center, and a Search Center with Tabs. The Publishing Portal also offers a number of default sites: a home page, a sample press releases subsite, a Search Center, and a login page. As their titles suggest, the Collaboration Portal template is designed for more collaborative site collections, whereas the Publishing Portal template is designed for publishing and sharing information.

These templates and their differentiating factors are covered in more depth in Part II, “Using SharePoint 2007 Technologies,” later in this book. Chapter 9 gives an introduction to the simpler standard templates. Chapter 12 covers the Records Center template and the Publishing Portal template.

The initial proof of concept phase should include testing of different standard templates to see whether one is well suited to the needs of the organization to use out of the box or whether a custom configuration is needed.

Planning Groups and Security Settings for SharePoint Server 2007

As the SharePoint environment gets larger, it becomes more important to carefully think through who will be filling each role for the farm as well as for site collections, and even subsites that will be heavily used. SharePoint Portal 2007 adds the new administrator role of Shared Services that needs to be filled by one or more users or accounts in addition to the Farm Administrators. The Shared Services administrators might be the same as for the farm, or a more limited group of administrators might have access to Shared Services tools. Shared Services tools include User Profiles and My Sites management tools, Search Configuration, Audiences, Excel Services, and Business Data Catalog.

In addition, a number of additional default groups are provided when SharePoint Portal 2007 is used. Windows SharePoint Services 3.0 offers only Members, Owners, Visitors and Anonymous User groups, whereas SharePoint Portal 2007 offers Members, Visitors, Owners, Style Resource Readers, Designers, Hierarchy Managers, Approvers, Restricted Readers, Quick Deploy Users, and Viewers.

Figures 4.4, 4.5, and 4.6 show the more complex grid of default groups and permissions. As with Windows SharePoint Services 3.0, it is a general recommendation to not change or delete these groups unless testing reveals that they won’t meet the organization’s needs.

Figure 4.4. Table of SharePoint Server 2007 groups and privileges (1 of 3).

image

Figure 4.5. Table of SharePoint Server 2007 groups and privileges (2 of 3).

image

Figure 4.6. Table of SharePoint Server 2007 groups and privileges (3 of 3).

image

Additional Design Decisions for SharePoint Server 2007

The same items highlighted in the previous section covering Windows SharePoint Services 3.0 also need to be discussed and configured to meet the end user community’s needs, as well as Shared Services for SharePoint Server 2007. If SharePoint Server 2007 Enterprise Edition is used, discussion should also involve which of the following tools will be used:

  • InfoPath forms services: This can be a complex discussion because it needs to address factors such as whether Forms Server be used, or will InfoPath be installed on individual workstations? Which business forms will be built in InfoPath? What testing process will be used? How is workflow involved, if at all, with the use of forms? A number of form templates are provided with SharePoint Server 2007, and these should be reviewed to see if one or more can be used as is or with minimal modification. The main settings that affect the user experience are on the Configure InfoPath Forms Services (_admin/ipfsConfig.aspx) page and include a decision about whether users can browser-enable form templates, and render form templates that are browser-enabled by users.
  • User profiles: User profiles are not offered in Windows SharePoint Services 3.0, but need to be planned to a certain extent in SharePoint Server 2007. Most organizations choose to stay with the default fields mapped from Active Directory to SharePoint, but might have reasons to add specific fields to the user profiles, or want to exclude certain AD fields from being imported in SharePoint. For example, home addresses might be tracked in AD, but the SharePoint design team does not want them imported in the SharePoint profile database. SharePoint Server 2007 allows for the management of profile policies. Figure 4.7 shows the Manage Policy page (ssp/admin/_layouts/ManagePrivacyPolicy.aspx) where you can see that components such as Memberships, My Colleagues, My Links, and My Personalization Links are enabled. These can be disabled one by one, if needed. In addition, the default visibility can be changed from Everyone to Only Me, My Manager, My Workgroup, or My Colleagues. The final option per item is that the user can be given the ability to override the default visibility. During the testing process, end users should give feedback on different combinations so that the organization can set standards in this area. Profile properties can be mapped to AD fields through the View Profile Properties page. (ssp/admin/_layouts/MgrProperty.aspx)

Figure 4.7. Manage Policy page.

image

  • Trusted My Site host locations: Other SharePoint servers can be configured to act as trusted My Site hosts and can be identified in Shared Services on the Trusted My Site Host Locations page (ssp/admin/Lists/Trusted My Site Host Locations). Target audiences can be set to determine which users’ My Sites are hosted in that location.
  • Published links to Office client applications: Also available in Shared Services, this gives the design team the opportunity to automatically have links show up under the My SharePoints tab when users open or save documents. The type of site needs to be identified (such as team site, document library, or slide library), and target audiences can be identified. (ssp/admin/Lists/Published links to Office client applications)
  • Personalization site links: Navigation links can be added to the My Site horizontal navigation bar between My Home and My Profile. Audiences can also be used if a link should appear for only certain users. (ssp/admin/Lists/Personalization site links)
  • Audiences: Audiences is a construct within SharePoint that allows specific users to see content differently from what other users see. Audiences are created and managed on the Manage Audiences page (ssp/admin/_layouts/Audience_main.aspx). When creating a new audience, a name is needed, an owner has to be defined, and then rules have to be defined. The audience can meet any of the rule or all the rules. Then the User operand can be used (Windows security group, distribution list, or organizational hierarchy) or a property can be selected from the user profile. The operators Contains, Not Contains, =, and <> are offered. For example, to build an audience of users with the area code 415 in their phone numbers, the Property option should be selected, Work Phone selected from the drop-down menu, the operator Contains selected, and then the value 415 entered. Now any user with the work phone value containing the numbers 415 would be a part of the group. This is less foolproof than using the Office property because the 415 might not be contained in the area code but in the actual body of the number, so testing for audiences is generally required. Audiences are a compelling reason that an organization might want to customize the SharePoint profile database. For example, a technical firm might want to know whether an individual has earned a certain industry certification and add a field called Professional Certifications to the profile database.
  • Excel Services: As discussed in Chapter 10, “Using Word, Excel, and Excel Services with SharePoint 2007,” Excel services can offer a powerful toolset for collaboration and for publishing information from spreadsheets, and so it might be an important part of the user environment. During the design and testing process, trusted file locations should be established (ssp/admin/_layouts/ExcelServerTrustedLocations.aspx). The organization can choose to make all locations trusted, to promote the use of Excel services, or only certain sites, such as the Accounting site collection.
  • Business Data Catalog: The Business Data Catalog is a Shared Service that stores information about line of business applications and their data types and properties so that they can be exposed for use by users within a site.
  • My Site Settings: This area of Shared Services provides for Personal Site settings across the Shared Services Provider (SSP).
  • Search Service: Farm-level search services can be set and managed on the Configure Search Settings page (ssp/admin/_layouts/searchsspsettings.aspx). Configuration options include adding content sources (such as websites, file shares, Exchange Public folders, or business data), which file types to include in the content index (for example, filename is not included by default, but could be useful to many organizations). If configured properly, SharePoint Server 2007 search can become the primary search engine for the organization and encourage users to search for and utilize resources that exist within the organization instead of starting from scratch. The return on investment for a few extra hours of work in this area can be considerable.

Customizing the Site Directory

The site directory is an important component of a site structure because if it is properly designed it allows users to quickly gain an understanding of the structure of the site collection, and navigate to the relevant top-level site of main site collections.

SharePoint Server 2007 allows the farm administrator to define which site directory, if there is more than one, is the Master Site Directory. Access the Operations tab, and select the Master Site Directory Settings link. This Site Directory Settings page will open (_admin/SiteDirectorySettings.aspx), and allow the entry of the site directory that will capture all new site collections. Additional settings include the following:

  • No Site Categories Are Mandatory
  • One Site Category Is Mandatory
  • All Site Categories Are Mandatory

Thought should be given to the structure of the site directory and the categories that will be used. A standard site directory page can be a little tricky to fine-tune. Figure 4.8 shows the category.aspx page that is set as the welcome page for the Site Directory on a SharePoint Server 2007 site collection. Links are available to create new tabs or edit tabs (identified with the number 1 in Figure 4.8). The page can also be customized by adding additional web parts, as indicated by number 2 in Figure 4.8.

Figure 4.8. Site Directory page in Edit mode.

image

Tip

For smaller organizations, setting the category.aspx page as the default welcome page may be off-putting to users. If there are a limited number of sites to choose from, the end users might prefer to have the sitemap.aspx page as the default page. To change this, access the Site Actions menu, click Site Settings, Modify All Site Settings, and then click Welcome Page in the Look and Feel column. Click Browse, choose Sitemap (Default), and click OK. Figure 4.9 shows the new default view. This allows users to immediately see the sites they are most likely interested in.

Figure 4.9. Site Directory page as default welcome page.

image

Designing My Sites

My Sites in SharePoint Portal 2003 offered users an environment that they could personalize to a certain extent, and create subsites, lists, and libraries to store a variety of different types of information and share information with others. Unfortunately, the home page was shared with all users, so modification options were limited. SharePoint Portal 2007 has added many new features to My Sites and they have now become a viable business tool, and tie the user in to the data in a number of impressive ways. Figure 4.10 shows a sample My Site that was customized in less than 15 minutes. One of the default web parts is Get Started with My Site, and it provides links that let the end users quickly customize the site and add a picture, and it instructs the individual on how to add web parts. Web parts that connect to Outlook Web Access servers enable users to create their own dashboards that include calendar information, their Task list, and even their inbox, if needed. The Memberships web part, shown in Figure 4.10, shows all the groups that the individual is a member of. Note that a Create Blog button is available under the Site Actions button, and the user has complete control over the site’s settings.

Figure 4.10. Sample My Site in SharePoint Server 2007.

image

A new offering that Microsoft is making available are role-based templates for My Sites. These can be found on the http://office.microsoft.com/en-us/sharepointserver site. Currently, the Sales Account Manager and Controller-Financial Analyst templates are available. Additional templates that should be available by the publishing date of this book include HR Manager, IT Manager, Marketing Manager, Customer Service Manager, and Administrative Assistant. These will allow an individual user to quickly provide new sites within their individual personal site. This will save time and speed up the adoption process for different users. SharePoint Server 2007’s Sign In as a Different User feature allows users to view different sites if sample sites are configured.

Planning the Desktop Configuration

In most implementations of SharePoint 2007, the desktop configurations have already been established and aren’t going to change dramatically, if at all. As with other testing processes, it is important to test each different desktop configuration with the SharePoint 2007 environment to finalize the design and prepare for the full rollout. Some components that enhance the SharePoint 2007 experience that pertain to the desktop include the following:

  • My Network Places: Adding SharePoint 2007 sites to My Network Places greatly facilitates the user’s ability to access and save to SharePoint sites and document libraries.
  • Monitor size: Bigger is better because SharePoint sites can get difficult to use (and involve a lot more use of the scrollbars) with smaller monitors, such as 17” monitors. Newer 19” and wide-format monitors make the user experience much more pleasant and productive. Designers and site admins should be provided with larger monitors for productivity purposes.
  • Anti-virus software in use: If a SharePoint 2007–specific virus-scanning solution is not implemented in the organization, there is a chance that infected files can be uploaded. Therefore, it is important for the standard desktop and laptops to have antivirus software installed.
  • Patches and updates: Whatever the desktop operating system is, the organization should make sure that the latest patches and updates are installed.

Adopting Windows Vista

At the time of this writing, Vista is just shipping. Users are already complaining about some features and raving about others. From an IT standpoint, Vista is the latest and greatest, and should be included in the SharePoint 2007 user environment proof of concept process.

Windows Vista has built-in integration with SharePoint Sites, allowing for SharePoint feeds to be displayed directly from the Vista Sidebar. In addition, SharePoint lists and document libraries can be directly accessed from the Vista Explorer.

Browser Options

Microsoft breaks browser support into two levels: Level 1 and Level 2. Level 1 browsers use ActiveX to take advantage of advanced features and provide the most complete level of integration with SharePoint 2007. They offer full functionality on all SharePoint sites, including the Central Administration website. Level 1 browsers include Internet Explorer 6.x (32-bit) and Internet Explorer 7.x (32-bit). Level 2 browsers provide basic functionality, enabling users to access sites, read and write data in SharePoint sites, and perform site administration. However, the user experience will not be as optimized as with Level 1 browsers, so these browsers should be tested more extensively if they are supported by the IT environment. Level 2 browsers include the following:

  • Firefox 1.5 (Windows, Linux/UNIX, Macintosh OS X)
  • Mozilla 1.7 (Windows)
  • Netscape Navigator 7.2 (Linux/UNIX)
  • Netscape Navigator 8.1 (Windows)
  • Safari 2.0 (Macintosh OS X)

If the browser in question is not listed in either the Level 1 or Level 2 lists, it is not supported by Microsoft and the user experience may not be acceptable. Obviously, Internet Explorer 7 is the recommended browser to use with SharePoint 2007 technologies, and most organizations are moving toward standardizing on Internet Explorer 7.

Tip

Make sure that the SharePoint server has been added to trusted sites in Internet Explorer, and that it has been set not to prompt for username. This can be accomplished using a Group Policy or manually in Internet Explorer 7 by accessing Tools, Internet Options, clicking the Security tab, selecting Trusted Sites, and clicking the Sites button. Enter the URL of the top-level SharePoint site (such as abcmoss01.abc.com) and click Add. Enter any aliases that will be used for testing as well. If SSL is not going to be used, uncheck the box next to Require Server Verification (HTTPS:) for All Sites in This Zone. Click Close. Back on the Security tab, click the Custom Level button, and select Automatic Logon with Current User Name and Password. Click OK and Yes when asked to confirm. Click OK to close the Internet Options window.

Mobile pages have a limited support for browsers installed in mobile devices. Mobile pages refers to those that can be accessed by using the following SharePoint 2007 URLs: http://URL/m/ or http://URL/_layouts/mobile/default.aspx. The following is a list of mobile browsers that are supported for use with SharePoint 2007 site in the United States, United Kingdom, Germany, France, and Spain:

  • Pocket Internet Explorer in Microsoft Windows Mobile for Pocket PC and in Smartphone
  • Nokia WAP 2.0 browser (xHTML only)
  • Motorola Mobile Information Browser 2.2 or later
  • Openwave UP.Browser 6.2 or 7.0 (and requires that the user agent contains one of the following strings: UP.browser/6.2 or 7.0)

Mobile devices and carriers supported in Japan are

  • NTT DoCoMo: FOMA series
  • au by KDDI: WIN series
  • SoftBank: 903SH, 902SH, 802SH, 703N, 703SH, 703SH
  • WILLCOM: W-ZERO3

Planning for Microsoft Office Product Integration

Microsoft designed the SharePoint 2007 product family to integrate the most completely with Office 2007 products. However, the reality of the business world is that many organizations will have older versions of the Office applications. In these situations, it is important to test the different applications in use and be prepared for the issues that end users might encounter. Chapter 10 provides more detailed information about the pros and cons of the 2007 and 2003 product lines with regard to Word and Excel, and Chapter 11, “Leveraging Additional Office 2007 Products in a SharePoint 2007 Environment,” adds some additional information, especially pertaining to Outlook.

A sampling of some key benefits of using the 2007 products is as follows:

  • Blog entries can be authored in Word 2007 and uploaded directly to a SharePoint 2007 blog.
  • Outlook 2007 indexes emails, contacts, tasks, calendar entries, RSS feeds, and other items to speed up the searching process.
  • Searches can be saved in search folders in Outlook 2007 and can include RSS feeds from SharePoint 2007.
  • Outlook 2007 includes a reader for RSS feeds published from SharePoint 2007.
  • Documents stored in SharePoint 2007 document libraries can be connected to Outlook, and online or offline edits and changes are automatically synchronized.
  • Access 2007 can synchronize with SharePoint 2007. This feature enables a user to use Access reports while using a SharePoint-based, managed version of the data.
  • SharePoint Designer 2007 enables designers to customize sites beyond what the web browser tools allow. Designer 2007 also provides tools that are valuable for creating more complex workflows.
  • When creating or working with existing content types in SharePoint 2007, the document information panel settings determine what level of information is displayed in Office 2007 applications. Custom templates can be uploaded. InfoPath 2007 can also be used to edit or create new templates.

Choosing the right version of Office 2007 will be important if the organization is planning to use some of the more advanced SharePoint 2007 features, such as the following:

  • Integrated Enterprise Content Management
  • Integrated Electronic Forms
  • Advanced Information Rights Management and Policy Capabilities

Reviewing Lessons Learned from Previous SharePoint Implementations

Now that the process of planning the SharePoint 2007 user environment has been covered, a review of a real world SharePoint 2003 growth pattern is provided to give SharePoint architects an idea of what a typical growth pattern looks like, and to prepare them for the growth that might occur.

Adoption Patterns for SharePoint

Actual figures can reveal a great deal about how organizations tend to adopt SharePoint. Figure 4.11 shows actual adoption figures for a SharePoint implementation in a 5,000 employee company (Company “X"). In this scenario, SharePoint Portal Server 2003 was the product implemented, and there was no active promotion of the capabilities of SharePoint. Certain early adopters found that the functionality made their lives easier, allowed them to create and control their own collaboration environments, and augmented the capabilities of their own intranet. Early adopters included various IT organizations, Marketing and Sales divisions, and Project Management.

Figure 4.11. Actual adoption numbers of SharePoint.

image

This organization also had a document management product from a company other than Microsoft in place, as well as a lively wiki environment. Still the use of SharePoint grew at a steady pace, as shown in Figure 4.11. Three images are included in this figure. The first summarizes unique authenticated users per month. The final number of 2,183 represents approximately 45% of the total users on the network, proving that half of all users accessed SharePoint during that month. Notice that July usage leveled off, most likely explained by summer vacations. The second graph shows average hits per day (recorded by WebTrends software), and shows a little less consistent picture, but still trending upward to a final number of 122,477 hits per day. The jump in hits per day in August was most likely due to extensive testing via automated processes to prepare for a migration to an improved, fault-tolerant SharePoint environment. Finally, the third graph shows the growth in database size at the organization. The final size was recorded at 56.55GB, but in early 2007 this had already reached 80GB. Analysis of this number revealed that roughly 25% of the total database content was comprised of document versions.

This information represents a typical adoption cycle by a 5,000 person organization that doesn’t actively promote the SharePoint product line, but has power users who adopt and promote the tool, and users who see the benefits of the features it offers and then start actively using the product.

Tip

Tracking the use of SharePoint from its implementation will yield helpful info on the adoption patterns, such as number of users who use it each month, total number of hits per day, and total amount of data stored. Additional information such as processor utilization patterns, RAM usage, and analysis of error logs can also provide valuable insight into the ability of the hardware to handle the changing demands of the environment. This enables the organization to plan for and manage growth, allocate appropriate numbers of support and training resources, and modify disaster recovery scenarios as needed.

Planning Architecture Upgrades Based on Usage

SharePoint 2007 architecture, as reviewed in the two previous chapters, has even more flexibility than the 2003 product family. Many organizations start with a small server farm and then, based on the level of adoption, expand the environment accordingly. It is natural for service level agreements (SLAs) to evolve as more users take come to depend on SharePoint for document management, workflows, alerts, and other features. When managers and executives get hooked, they might well start inquiring about maximum downtime and what-if scenarios.

A natural progression is to start with a less fault-tolerant, two-tier environment and then upgrade to a more complex, three-tier environment. An initial two-tier environment consisting of production and staging tiers limits the initial expenditure on hardware and software, but still provides SLA levels of 99.9% uptime. The development tier is used to test new web parts and third-party applications, as well as to test new operating system and SharePoint patches. In addition, the development tier can be part of the fault tolerance plan in case hardware from the production environment fails. A sample configuration could be as follows:

  • Production: One front-end server (Windows Server 2003, SharePoint Server 2007)
  • Production: One back-end server (Windows Server 2003, SQL Server 2005)
  • Development: One front-end server (Windows Server 2003, SharePoint Server 2007)
  • Development: One back-end server (Windows Server 2003, SQL Server 2005)

As more users become trained in the use of the software, department- or project-specific sites fill up with dynamic and appealing content, users come to trust the environment, and managers come to depend on the information provided, an upgrade can be discussed. A logical upgrade at this point is to a three-tier environment, consisting of production, staging, and development. A sample configuration might be as follows:

  • Production: Two load-balanced, front-end web and search servers (Windows Server 2003, SharePoint Server 2007)
  • Production: One front-end application server (Index Server, Shared Services, Excel Services, Windows Server 2003, SharePoint Server 2007)
  • Production: One back-end server (Windows Server 2003, SQL Server 2005)
  • Staging: Two load-balanced, front-end web and search servers (Windows Server 2003, SharePoint Server 2007)
  • Staging: One front-end application server (Index Server, Shared Services, Excel Services, Windows Server 2003, SharePoint Server 2007)
  • Staging: One back-end server (Windows Server 2003, SQL Server 2005)
  • Development: One front-end web and search server (Windows Server 2003, SharePoint Server 2007)
  • Development: One front-end application server (Index Server, Shared Services, Excel Services, Windows Server 2003, SharePoint Server 2007)
  • Development: One back-end Server (Windows Server 2003, SQL Server 2005)

Although the actual server configuration will vary by organization, by tracking the usage patterns, the organization can determine when and where upgrades are needed.

Typical Problems Encountered

Based on the initial implementations of SharePoint 2007 performed at the time this book was being written, it appears that the typical problems encountered by the user community with SharePoint 2003 are the same as with SharePoint 2007. However, due to the additional complexity of SharePoint 2007, proof of concept testing and end user training are even more important. Some key issues encountered are as follows:

  • Controlling the growth of the environment: Most organizations choose not to let end users create top-level site collections. Instead a request form is completed and IT is given a chance to review it, and either grant it or determine that the site should in fact be created below an existing site, and involve the administrator(s) of that top-level site.
  • Basic access and usage issues: Users inevitably try to access sites they don’t have permission to or wrestle with SharePoint authentication, if it is different from what they are used to. Because document libraries and lists offer more features in SharePoint 2007, and there are many new web parts, site templates, and advanced features, these problems are naturally more common.
  • Supporting different versions of desktop operating systems, Microsoft Office, and browsers: Most organizations have different versions of Microsoft Office products in use, and support will vary based on the combination of products in use. Likewise, several different operating systems are probably in use, requiring greater levels of support. SharePoint 2007 offers more integration points with Office 2007 products which users will want to leverage and understand.
  • Site customization: Site administrators and site collection administrators are excited by the new features in SharePoint 2007 sites, lists, and libraries, but will require additional handholding to ensure that the environments aren’t overly complex to begin with. Issues as basic as creating new views and adding columns, or more extensive ones such as document-level security, publishing processes, and workflows need to be addressed.
  • Use of SharePoint Designer 2007: A small percentage of users and designers need to access the rich feature set of Designer 2007.
  • Restoring lost files, document libraries, or sites: SharePoint 2007’s Recycle Bin functionality greatly reduces the need for IT to recover or restore items. However, when a request does come through for recovery, the issue is usually quite complex (for example, “I think I deleted a file two months ago").

Staffing for SharePoint Support

It is also revealing to look at the staffing levels that were in place, and consider how the needs of SharePoint 2007 might be different. For company “X,” SharePoint support was provided by a Web Services group that consisted of two managers and three staff members. A SQL administrator assisted with SQL-specific tasks, and a large number of server administrators were available for hardware-related issues. Data was stored on SAN devices, and staff was available for support of these devices. Thus, for a 5,000 person company, the support was as follows:

  • One director-level resource for guidance and vision (minimal day-to-day involvement).
  • Two managers for day-to-day guidance on processes and procedures (minimal day-to-day involvement).
  • Three SharePoint-specific administrator resources dedicated to SharePoint maintenance and end user support (full-time resources).
  • One SQL resource available business hours for SQL-specific tasks (minimal day-to-day involvement).
  • Server support staff on call 24/7 for operating system patching, server reboots, or troubleshooting.
  • The help desk staff were trained on basic troubleshooting issues, such as login errors and Internet Explorer configuration basics, and was a first line of defense.

Certain departments chose to hire a full-time support resource to train users, customize the SharePoint environment, and act as a liaison to discuss departmental needs and requirements for third-party add-ons and custom functionality. Other departments selected a power user to be the central point of contact for SharePoint-related questions.

In effect, the power users became an extended part of the SharePoint support infrastructure because they became the first level of support to users in their departments and groups. Rather than submit help desk tickets, end users could simply ask someone they knew to be an expert to assist them—a good example of a successful Train the Trainer model.

So, even as more users worked with SharePoint on a daily basis, the overall support requirements did not increase. The early adopters evolved to be trend setters and an informal tier of support, whereas the help desk could handle more issues shielding the dedicated SharePoint support resources.

Summary

This chapter continues the design process with the needs of the end user community in mind. Otherwise, the ideal hardware and software combination might have been selected, but the result might not thrill the end user community or it might overwhelm them. Many of the topics introduced in this chapter are expanded on in future chapters so additional information is available to better understand the possible configurations. Key decision areas for Windows SharePoint Services 3.0 were reviewed first, for readers involved in the design of simpler environments, and then SharePoint Server 2007 design areas are provided. Some discussion was provided on the advantages of different desktop operating systems, browsers, and versions of Office (additional discussions of the differences between Office 2003 products and Office 2007 products are provided in Chapters 10 and 11). The chapter concluded with a short review of real world adoption patterns of SharePoint as well as some thoughts on staffing levels.

Best Practices

  • Several key documents should be created when designing the SharePoint 2007 user environment. These should include the end user design document, testing procedure, implementation plan, training and support plan. These should augment any hardware and software design documentation.
  • If Windows SharePoint Services 3.0 has been selected as the software platform, although the design process is simpler, there are still many design decisions that have to be made. To begin with, will there be one or multiple site collections. If there will be multiple site collections, a number of configuration decisions that are set from the Central Administrator console and from the top-level site Site Settings page need to be made, as outlined in this chapter.
  • A general best practice for Windows SharePoint Services 3.0 or SharePoint Server 2007 is to limit the number of site collections to the bare minimum during the proof of concept and testing phases to get a better understanding of the SharePoint administrators’ skill sets and ability to manage the entire site collections.
  • Another best practice is not to turn off the default list permissions, site permissions, or personal permissions on a site. Troubleshooting user access issues can be much more time-consuming if certain items are deactivated.
  • Windows SharePoint Services 3.0 offers the Members, Owners, and Visitors groups by default. In general, the default groups should be used during the testing phase to see whether they will meet the needs of the organization. Use the information in this chapter to determine whether additional groups are needed.
  • By default, the Windows SharePoint Services 3.0 Farm Administrator group includes the Builtin/Administrators group that corresponds to the Local Administrator group on the server. Consider whether this offers the level of security needed for the SharePoint environment. If not, remove this group from the Farm Administrators group.
  • Audiences come into play in many places in SharePoint Server 2007 and can be based on user properties (Windows security group, distribution list, or organizational hierarchy) or profile properties.
  • The configuration of SharePoint Server 2007 search options can greatly affect the value that the users get from SharePoint, and so should be carefully reviewed. The content sources outside SharePoint data (such as file shares or Exchange Public folder data) should be considered, and the metadata property mappings deserve a thorough review.
  • Ideally, Office 2007 applications would be the standard in an organization implementing SharePoint 2007, but the real world is seldom this way. Make sure to thoroughly test the standard versions and Office applications in use with the proof of concept SharePoint 2007 environment to prepare training for the end users and train the help desk for standard issues encountered.
  • Some real world adoption examples were given at the end of the chapter. This information gives insight into a sample adoption pattern that shows how users gradually come to adopt and depend on SharePoint technologies. This section might help architects and designers fine-tune their implementation strategies.
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset