Microsoft SharePoint 2010: Mandatory Services in SharePoint

There are both mandatory and optional services you can identify and activate within Microsoft SharePoint 2010.

Steve Wright and Corey Erkes

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.

Mandatory Services

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.

Infrastructure Services

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

Hardware Infrastructure

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:

• 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 you store in the portal, including all versions and types of documents?
• Storage type: Will all content be stored on a single SQL Server, NAS or a SAN? Will you need to access any data using SQL Server Remote BLOB Service (RBS)?
• Network bandwidth: How much data will the portal send and receive?
• Network routing: Will you need a network load-balancing appliance? 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 and PerformancePoint Services? These services can be hosted on front-end Web servers, but this can degrade performance.

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

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:

• Classic  authentication is the same mechanism used by most Web sites and the previous versions of SharePoint. This system checks credentials against a Windows identity provider, either Active Directory (Windows NT LAN Manager) or Kerberos. The information 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 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, 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:

• 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’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

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:

• Domain identities are the user and group names defined by the claims or classic provider used to log in to the system. Once the user is logged into SharePoint, domain user and group names are used identically. You can’t alter the members of a domain group from within SharePoint.
• SharePoint groups let you group domain users and groups together to simplify managing permissions. You can edit SharePoint groups through the Web interface. You can also configure them to let members add themselves or request membership from the group owner. One disadvantage of SharePoint groups is that they’re specific to the site collection in which they’re created. You can’t reference them across multiple collections.

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:

• Will you manage group memberships in SharePoint Groups or domain groups? SharePoint groups are defined only within each site collection, but you can easily manage them through the Web interface. Domain groups are global, but you have to maintain them 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, you can alter or create new levels to suit your situation.
• Site owners typically assign permissions within their sites. Who will own each site and how will you transfer ownership when users leave the organization?
• Who will be responsible for removing access from users that leave the organization?

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.

E-Mail Integration

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:

• 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 you access an outside e-mail server?
• What security configurations are required to forward e-mail into and out of the SharePoint farm?
• How will you configure the e-mail servers and firewall 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 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.

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

• Ensure that Web traffic to the CA site can’t 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 doesn’t 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.
• You can move the CA Web site from one server to another using the SharePoint Products and Technologies Configuration Wizard.
• You can change the randomly assigned port number assigned to the CA Web site at installation using the Windows PowerShell Set-SPCentralAdministration cmdlet.

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.

Steve Wright is a senior manager in Business Intelligence Management for Sogeti USA LLC in Omaha, Neb. Over the last 20-plus years, Wright has worked on air traffic control, financial, insurance and a multitude of other types of systems. He has authored and performed technical reviews for many previous titles covering Microsoft products including Windows, SharePoint, SQL Server and BizTalk.

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.

Related Content

• SharePoint  2010: The Purpose of Governance
• SharePoint Online: Get Started with SharePoint Online
• SharePoint 2010: Microsoft SharePoint Online: An Overview for Enterprise IT Professionals