Identifying Services

The services to be implemented in a SharePoint portal will fall into one of three categories. The first and most common type of service is inherent in the SharePoint product line, such as Publishing or PerformancePoint Services. (We will discuss some of these later in this chapter.)

A service can also be built around a third-party product that provides features on top of SharePoint. Common examples of this are data archiving, workflow, and image/document management systems. These products require separate licensing and configuration beyond that of the SharePoint server itself. When implementing this type of service, be sure to evaluate the vendor's upgrade practices. If the vendor publishes patches and interim versions (point releases) between major releases, these release schedules will need to be integrated with the portal's maintenance schedule. Some commercial add-ons also require special hardware such as storage or networking infrastructure.

A third source of services may be your own Information Technology (IT) department. Custom-built applications built on SharePoint can provide an excellent return on investment because they can provide value to the business that cannot be achieved in other ways. A custom solution might be as simple as automating a business process using a set of InfoPath forms and workflows. It could also involve significant .NET Framework programming to implement new Web Parts, event handlers, workflow activities, or background processes (timer jobs).

Other sources of solutions for SharePoint are open- or shared-source sites such as CodePlex.com. CodePlex is sponsored by Microsoft and, as of November 2011, contains almost 1,700 open source projects for SharePoint. These projects include Web Parts, best practices, site templates, management and administration tools, and so on. These projects are provided on an “as is” basis and are not supported by any vendor. Therefore, from a governance point of view, these should be treated in the same way as internally created custom solutions. The advantage to using open source solutions is that much of the work is already done.

The other way to categorize services in SharePoint is as mandatory or optional. Mandatory services are those that must be present at all times in order for the system to function. We will describe some of these later in this chapter. Note that the mandatory services described are required for technical reasons. Your organization may have regulatory or compliance needs that will require some otherwise optional services to be made mandatory. For example, a portal that is hosting corporate records subject to Sarbanes-Oxley regulations may require SharePoint's records management features to be available.

Optional services are those that are deployed because they provide value to the organization. Some services will depend on other services in order to function properly. For example, to use SharePoint's automated content deployment mechanism, you must also be using the Publishing features. While it may be tempting to lump a group of interdependent features into a single service, remember that the goal is to simplify governance of each service. Combining features with different audiences, requirements, and monitoring capabilities into a single service will make that service more difficult to manage.

Establish Mandatory Services

In this section, we will describe the most important mandatory services that the governance team needs to be aware of. These services should be evaluated and planned before any servers are installed.

Infrastructural Services

The infrastructural services form the foundation for the rest of the system.

Hardware Infrastructure

When planning the hardware for a SharePoint environment, the governance team in conjunction with IT will need to perform capacity planning. Capacity planning involves creating a profile of how the system will be used and the level of performance to be expected. Much of this information may be laid out in a Service Level Agreement (SLA) between the governance team and the user community.

When developing the hardware plan for a portal, consider the following:

• User load: How many users will be using the system at one time? Which services will be most heavily used?
• Storage volume: How much data will be stored in the portal, including old versions and all types of documents?
• Storage type: Will all content be stored on a single SQL Server, Network Attached Storage (NAS), or a Storage Area Network (SAN)? Will any data be accessed using SQL Server's Remote BLOB Service (RBS)?
• Network bandwidth: How much data will be sent and received by the portal?
• Network routing: Will a network load balancing appliance be needed? What about new firewall settings?
• Server tiers: All SharePoint portals require one or more web servers and one or more database servers. Does your portal need separate search query and indexing servers? What about other application tier services such as Excel Services, Access Services, or PerformancePoint Services? These services can be hosted on the front-end web servers, but this can cause performance to degrade for end users.

Even the best capacity plan is never perfect. As time passes, content tends to become larger. If your portal is successful, the addition of new services and more active users will increase load on the servers.

When the farm is initially deployed, collect a set of performance and usage metrics. These will form a baseline that can be used for comparison later. As the system's load and storage size increase, these measurements will allow the governance team to proactively predict when additional hardware resources will be needed. This will prevent end users from noticing a slow-down in the system that can cause them to abandon their use of the portal.

Authentication

Authentication is the means used to identify users when they connect to the portal. This usually involves providing a user name and password, but where those credentials are stored and how they are validated can vary greatly. SharePoint supports two modes of authentication: classic and claims-based.

• Classic mode authentication is the same mechanism used by most web sites and the previous versions of SharePoint. Credentials are checked against a Windows identity provider, either Active Directory (NTLM) or Kerberos. The information obtained includes basic attributes about the user including the security groups to which they belong.
• Claims-based authentication is new in SharePoint 2010. A claim is a set of information about a subject that is provided by a trusted claim provider. This information is delivered in an encrypted security token issued by the provider. The user presents the claim as evidence of their identity in order to use the system.

Active Directory and Kerberos, and many other providers, can also be used as claims-based authentication providers. When performing forms-based authentication (where the user logs on with credentials stored in a database, for example) components known as membership and role providers act as the providers of the claims. Another common technique is to use a centralized identity store such as Windows Live ID to provide claims using the Security Assertion Markup Language (SAML).

Considerations for authentication include:

• Where will the user's name and password be stored?
• How will the user change their password?
• Who will create and deactivate users?
• What configuration is necessary to bring those credentials into SharePoint?
• How will the portal establish a trust relationship with its claims providers?

It is not uncommon to use multiple forms of authentication within a single SharePoint farm. For internal users on an intranet, the most common form of authentication is Active Directory. Kerberos is becoming more popular as more administrators become familiar with it.

For external users on an extranet or a public web site, it is often impractical to use Active Directory. More often, forms-based authentication or an Internet-based identity service such as Windows Live is used.

The decision to use claims or classic mode authentication will depend on the type of authentication to be performed. In general, if there is no need to use classic mode authentication, new SharePoint installations should use claims-based mode.

Authorization

Authorization refers to the process of determining which users are allowed to perform which actions. If authentication answers the question “Who are you?”, then authorization is concerned with “What can you do?” To understand authorization in SharePoint, you will need to master the four concepts shown in Figure 4-2.

Figure 4-2. Authorization process

We have already touched on the first concept, identity. A user's identity includes their user name and any security groups to which they belong. There are two types of identities within SharePoint: domain and SharePoint groups.

• Domain identities are the user and group names defined by the claims provider or classic mode provider used to log in to the system. Domain user and group names are used identically once the user is logged in to SharePoint. The members of a domain group cannot be altered from within SharePoint.
• SharePoint groups allow domain users and groups to be grouped together to simplify managing permissions. SharePoint groups can be edited through the web interface. They can also be configured to allow members to add themselves or to request membership from the group owner. A disadvantage of SharePoint groups is that they are specific to the site collection in which they are created. They cannot be referenced across multiple collections.

A securable object is any object within SharePoint that can have permissions assigned to it. This includes items such as sites, site collections, lists, libraries, and list or library items. These are the objects to which access is to be authorized.

A role definition defines a permission or an action to be taken. Examples would include view a site, edit a list item, and delete a page. Additionally, SharePoint allows the creation of permission levels. A permission level is a group of permissions that have been declared as a unit. Assigning a user a permission level for an object grants them all of the rights associated with that permission level. Some common permission levels include Full Control, Contribute, Read, and Design. Permission levels can be created and edited within SharePoint's web interface. Like SharePoint groups, permission levels are defined within a single site collection.

The last concept to be understood is that of an assignment. An assignment is created when a user (identity) is given a certain set of permissions (role definition) to a piece of content (securable object). An assignment establishes a three-way connection between the identity, role definition, and object described above to define the rights of any user that might attempt to access the object.

When a user attempts to access an object, SharePoint searches for any assignments for the identities associated with that user. These include the user's domain user ID, all domain groups, and any SharePoint groups to which the user belongs. The resulting list of assignments is used to determine the rights the user has to the object.

The two items that will be most important to plan are the permission levels and SharePoint groups to be created. Here are some things to keep in mind:

• Will group memberships be managed in SharePoint Groups or domain groups? SharePoint groups are defined only within each site collection but they can be easily managed through the web interface. Domain groups are global, but they must be maintained outside of SharePoint.
• How will users request and be granted access to each group?
• Are the standard permission levels provided by SharePoint appropriate for your needs? If not, they can be altered, or new levels can be created to suit your situation.
• Site owners typically assign permissions within their sites. Who will own each site and how will ownership be transferred when users leave the organization?
• Who will be responsible for removing access from users that leave the organization?

A last concept to understand with regard to authorization is inheritance. Each object within a SharePoint site collection has a parent object from which it can inherit its permission assignments. Sites inherit from their parent site, lists inherit from the site that contains them and list items inherit from their parent list.

By default, a new item will inherit the permission of its parent object. This inheritance can be broken by an authorized user. Breaking inheritance causes the assignments from the parent object to be copied to the child object. As a result, the child will still have the same permissions as the parent, but any changes made to the child's permissions later will not affect the parent. Any objects which inherit permissions from the child will continue to do so, but now they will get the permissions directly from the child, not from its parent.

E-Mail Integration

While e-mail integration is not strictly mandatory for SharePoint to function, it is important enough in most cases to be considered mandatory. Many features within SharePoint will not function without the ability to send out e-mails. Two examples of these are workflow, which must be able to notify users of their tasks, and alerts, which cannot be sent except through e-mail.

SharePoint has two separate e-mail configurations: incoming and outgoing. Outgoing e-mail is used to provide alerts and notifications for workflows and certain administrative events. Incoming e-mail is used to allow users to participate in e-mail discussion lists, send documents into a document library, or submit other types of data into SharePoint.

When designing e-mail integration for your portal, consider these questions:

• Outgoing e-mail is needed in most intranet portals. Is incoming e-mail really needed or desirable?
• Will the local SMTP service be used on the web servers or will an e-mail server outside the farm be accessed?
• What security configurations are required to forward e-mail into and out of the SharePoint farm?
• How will the e-mail servers and firewall be configured to prevent the SharePoint site from being used as a relay point for SPAM e-mail traffic?
• How will incoming SPAM be filtered from the SharePoint mailbox?

SharePoint uses the SMTP protocol to send and receive e-mail from an e-mail server. A common scenario is to configure the Windows SMTP Service on one or more of the SharePoint servers in the farm, but any SMTP-enabled server application can be used. When using the local SMTP service it is usually necessary to configure it to relay messages to another server for final delivery. This can create a security hole if it is not configured carefully. Be sure to involve network engineers before deploying any new SMTP servers within your network.

Administration and Monitoring

Administration and monitoring services provide administrators with the ability to configure and monitor the SharePoint server farm.

Central Administration

SharePoint's primary administration interface is the Central Administration (CA) web site. This web site contains tools for almost all administrative functions within SharePoint. This web site must exist on exactly one SharePoint server within the farm. Using this site, farm administrators can create new web sites and site collections, configure farm services, and allocate resources and quota limits, and a multitude of other tasks using a simple web interface.

Some best practices and tips regarding Central Administration include

• Ensure that web traffic to the CA site cannot originate on the Internet. Use firewall settings or network routing to prevent access to hackers.
• Consider hosting the CA web site on an application tier server that does not communicate with the Internet.
• Limit the number of farm administrators. Only highly-trained personnel should be allowed to access CA.
• Keep a log of all changes made through CA.
• The CA web site can be moved from one server to another using the SharePoint Products and Technologies Configuration Wizard.
• The randomly assigned port number assigned to the CA web site at installation can be changed using the Windows PowerShell Set-SPCentralAdministration commandlet.

While most administrative actions can be performed using the CA interface, some will require the use of SharePoint's command-line tools. The Windows PowerShell interface allows administrators to write sophisticated, object-oriented administration scripts. This is the preferred scripting tool for SharePoint 2010. The STSADM tool used in previous versions of SharePoint is still available in 2010 but is considered deprecated and is included only to support backward compatibility.

Logging and Tracing

SharePoint uses a Universal Logging System (ULS) to consolidate trace information from all of the various components that make up the product. These logs can become very large. Adequate space must be allocated to store them or the system may be unable to record critical data. Also, if the default location on the system's C-drive is used, the logs can fill up the system drive and cause the system to fail.

These logs should always be moved to another drive specifically allocated for log files. Note that the log files on each server in the farm are stored in the same location. Therefore, the log file location must exist on every server in the farm. This may require provisioning additional disks.

For more detail on the configuration options associated with SharePoint's log files, see Chapter 7.

Usage and Health Data Collection

SharePoint can be configured to collect extensive information about the usage of the system. This information provides valuable feedback about how users are using the system. Which sites are visited most often? Which features are used most often? SharePoint can also automatically evaluate the state of the server farm and provide proactive alerts when problems are detected.

For more detail on usage and health data collection, see Chapter 7.

Identify Optional Services

Now that the mandatory services have been identified and planned out, we will discuss the optional services provided by SharePoint out of the box. Your organization may choose to package these services differently according to your own governance needs. This discussion will focus on the governance considerations associated with each feature.

Microsoft categorizes the features of SharePoint 2010 using the SharePoint wheel diagram shown in Figure 4-3. We will use the same categorization to explore the potential services provided by SharePoint.

Figure 4-3. The SharePoint wheel

Sites

Services in the Sites category allow users to create and manage web sites within the portal (see Table 4-1).

Content

These services provide users with the ability to create and manage content within their sites (see Table 4-2). All of these topics are covered in more detail in Chapter 6.

Communities

The SharePoint community services encourage collaboration and productivity by centralizing the sharing of information in the portal (see Table 4-3).

Composites

These services provide users with the ability to create composite applications. These are solutions that draw from multiple technologies and data sources. (See Table 4-4.)

Insights

These services enable enterprise data to be visualized and analyzed using advanced interactive tools (see Table 4-5).

Figure 4-4. A dashboard for business intelligence

Search

SharePoint's search capabilities extend well beyond the portal itself. SharePoint search can include content from other web sites, network file shares, Exchange folders, and more (see Table 4-6).

Prioritize Services

Now it is time to plan the deployment of the features to be supported on the portal. Your governance team has compiled a list of mandatory services and a list of optional services. The next step is to determine which services will be supported immediately after the launch of the site.

At first, the impulse to say “I want it all!” may be overwhelming. However, there are several reasons why it may be a good idea to roll out services over time instead of all at once. Consider these items when planning the order and release schedule for your services:

• Mandatory services have to be deployed when the portal is initially deployed.
• Training IT staff and users on all of the features being deployed may be unrealistic. Rolling out features that aren't ready to be supported or used is a recipe for failure.
• There is a trade-off between time to market and functionality. Implementing more functionality in the initial rollout will necessarily delay that rollout.
• Governance-related tasks such as collecting requirements, establishing policies and standards, negotiating SLAs, and deploying monitoring tools need to be factored into the timeline of the deployment of each service.
• It is often a good idea to target the features in the first release toward a specific set of highly-motivated users. These are the users that are most eager to use the system and will reap the biggest “quick win” for the organization.
• The initial deployment will create a multitude of lessons learned. By rolling out services over time you allow the IT staff, users, and governance team members to learn from their challenges (a.k.a. mistakes, problems, errors, and boo-boos).
• Some services require the presence of other services in order to function. If a feature is included in a release, all services upon which it depends must be included in that release or an earlier one.

Once the order of deployment is determined and a rough timeline is projected for each, it should be possible to spot a good cutoff point for the initial deployment. For example, if adding a group of services will delay the launch of the portal by a month or two, it may make sense to release without them and add them into the portal down the road.

The governance team will need to consult with users, business owners, and technical staff to determine the best way to achieve value quickly and sustainably. The goal is to deliver functionality at the moment the business is ready to leverage it. Deploying features too early can result in poor adoption and wasted resources. Deploying services after they are needed can result in angry users, lost opportunities and the unwanted substitution of another solution for the problem. This last result can also cause poor adoption and a waste of resources.