There are both mandatory and optional services you can identify and activate within Microsoft SharePoint 2010.
Adapted from “Pro SharePoint 2010 Governance” (Apress, 2012)
At the most basic level, you can categorize SharePoint services as mandatory or optional. The mandatory services are those that must be present at all times in order for the system to function. These are required services 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’s hosting corporate records subject to Sarbanes-Oxley regulations might require SharePoint records management features to be available.
Optional services are those you deploy because they provide value to the organization. Some services will depend on others in order to function properly. For example, to use the SharePoint automated content deployment mechanism, you must also be using the Publishing features.
While it might be tempting to lump a group of interdependent features into a single service, the goal should be 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.
This list includes the most important mandatory services of which your SharePoint governance team needs to be aware. You will need to evaluate and plan for these services before installing any SharePoint servers.
The infrastructure services form the foundation for the rest of the system.
When planning hardware for a SharePoint environment, you and the rest of your IT team will need to work with the governance team on capacity planning. Capacity planning involves creating a profile of how you’ll be using the system and what performance level you’ll expect. Your team can present much of this information within a service-level agreement (SLA) between the governance team and the user community.
When developing the hardware plan for a portal, consider the following:
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 you initially deploy your server farm, collect a set of performance and usage metrics. These will form a baseline you can use for comparison later. As the system load and storage size increases, these measurements will help the governance team proactively predict when you’ll need additional hardware. This will prevent end users from noticing a system slow-down that could cause them to abandon their use of the portal.
Authentication is the means by which the system identifies users when they connect to the portal. This usually involves providing a user name and password. The location where you store those credentials and how they’re validated can vary greatly. SharePoint supports two modes of authentication—classic and claims-based:
Active Directory, Kerberos and many other providers can also serve 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 claims providers. 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).
Authentication considerations include:
It’s 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’s often impractical to use Active Directory. It’s more common to use forms-based authentication or an Internet-based identity service such as Windows Live.
The decision to use claims-based or classic authentication will depend on the type of authentication you need to perform. In general, if there’s no need to use classic authentication, new SharePoint installations should use claims-based mode.
Authorization refers to the process of determining which users are allowed to perform which actions. Authentication answers the question, “Who are you?” Authorization is concerned with, “What can you do?”
The first concept within authorization is 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:
A securable object is any object within SharePoint that can have permissions assigned. This includes items such as sites, site collections, lists, libraries, and list or library items. These are the objects to which access is authorized.
A role definition defines a permission or an action to be taken. Some examples of this include view a site, edit a list item and delete a page. SharePoint also lets you create 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 rights associated with that permission level. Some common permission levels include Full Control, Contribute, Read and Design. You can create and edit permission levels within the SharePoint Web interface. Like SharePoint groups, permission levels are defined within a single site collection.
The last concept to be understood is that of assignments. An assignment is created when you give a user (identity) 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 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 for in advance are the permission levels and SharePoint groups you’ll want to create. Here are some things to keep in mind:
One 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. An authorized user can break this inheritance. 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 later made to the child’s permissions will not affect the parent. Any objects that inherit permissions from the child will continue to do so, but now they’ll get the permissions directly from the child, not from its parent.
While e-mail integration isn’t strictly mandatory for SharePoint to function, it’s important enough in most cases to be considered mandatory. Many features within SharePoint won’t function without the ability to send e-mails. Two examples of these are workflow, which must be able to notify users of their tasks, and alerts, which you can only send through e-mail.
SharePoint has two separate e-mail configurations: incoming and outgoing. Outgoing e-mail provides alerts and notifications for workflows and certain administrative events. Incoming e-mail lets users 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:
SharePoint uses the SMTP protocol to send and receive e-mail from a mail server. A common scenario is to configure the Windows SMTP Service on one or more of the SharePoint servers in the farm, but you can use any SMTP-enabled server application. When using the local SMTP service, it’s usually necessary to configure it to relay messages to another server for final delivery. This can create a security hole if it’s 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 help you configure and monitor the SharePoint server farm.
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, you can create new Web sites and site collections, configure farm services, allocate resources and quota limits, and perform a multitude of other tasks using a simple Web interface.
Some best practices and tips regarding CA include:
While you can perform most administrative actions using the CA interface, some will require that you use the SharePoint command-line tools. The Windows PowerShell interface lets you 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 it’s considered deprecated and is included only to support backward compatibility.
Logging and Tracing
SharePoint uses a Universal Logging System to consolidate trace information from the various components of the product. These logs can become very large. You’ll have to allocate adequate space 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, logs can fill up the system drive and cause system failure.
You should always move these logs 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.
Usage and Health Data Collection
You can configure SharePoint to collect extensive information about system usage. This information provides valuable feedback about how users are using the system. Which sites do they visit most often? Which features do they use most often? SharePoint can also automatically evaluate the state of the server farm and provide proactive alerts when problems are detected.
There are a host of additional, optional services you can identify and activate within SharePoint, but this covers the mandatory services that form the core of SharePoint service offerings.
Corey Erkes is a manager consultant for Sogeti USA LLC in Omaha, Neb. Erkes has worked with a wide range of companies at different points in the lifecycles of their SharePoint implementations. He’s also one of the founding members of the Omaha SharePoint Users Group.