Essential SharePoint 2013: Practical Guidance for Meaningful Business Results (2014)
Part I. Planning
Chapter 9. Understanding Architecture Fundamentals
No matter your role, you’ll want to understand the fundamental structure and core terminology of SharePoint 2013, since it will influence many choices you make, such as internal business ownership and total infrastructure costs. After reading this chapter, you’ll understand the difference between sites and site collections, what shared services are and how they’ve changed, and why you may need as many as 20 servers or as few as zero.
If you’re using SharePoint Online (either stand-alone or as part of the Office 365 suite), Microsoft is running the core infrastructure in the cloud. That said, you’ll still need to understand how site collections, sites, and service applications will impact your overall solution, along with how you might consider connecting your on-premises environment to a cloud-based one.
In this chapter, we’ll cover the following topics to help you think about your SharePoint service from a high-level design perspective:
New features of SharePoint 2013
An overview of key SharePoint functions
Sites, site collections, templates, and services
Managing SharePoint administration
Deployment options
What’s New In SharePoint 2013?
In general, SharePoint 2013 retains the fundamental architecture of SharePoint 2010. Topology concepts such as flexible server roles (including Web Front Ends, application servers, and database servers) are still in play. In addition, the logical hierarchy of SharePoint, which includes Web applications, site collections, sites, and lists, is untouched.
New items include the following:
The consolidation of SharePoint search and FAST search into a single search offering
The removal of workflow and Office Web Apps as internal SharePoint offerings (and into stand-alone services)
The introduction of the cloud as a tier-one architecture option
A Functional Overview
Let’s first review the key components of Microsoft SharePoint 2013 and associated dependencies, including the operating system, database services, SharePoint Foundation, SharePoint applications, and SharePoint application services. It is important to understand which functionality is provided by which component, and how these components relate to each other.
Operating System
Microsoft SharePoint Server 2013 is built on top of SharePoint Foundation, which, in turn, is built on top of the technologies and services provided by Microsoft Windows Server 2008 or 2012. The core platform services use the Microsoft .NET 4.x Framework. This combination of Windows and .NET provides SharePoint with the following technologies:
Internet Information Services 7/8 (for hosting Web applications)
ASP.NET master pages, content pages (Web Part pages), Web Parts, personalization, membership, navigation
Azure Workflow
Database Services
Microsoft SQL Server (either SQL 2008 SP1 R2 or SQL 2012) is the relational database used for storing all content, data, and configuration information used by SharePoint 2013, including documents and other BLOBs uploaded by users. All content (including large documents) is stored in the database, and not as files in the file system. SharePoint does provide an option for storing BLOBs outside of the database; this option is called Remote BLOB Storage (RBS). Several third-party vendors, and Microsoft itself, provide options for storing documents outside of the SQL Server database via RBS.
Since SQL Server is required for SharePoint, other relational databases, such as Oracle or MySQL, do not work and are not supported. If a separate database is not specified during installation, a specialized version of SQL Server 2008 Express is installed locally. The SharePoint-specific version of SQL Server 2008 Express has a database limit of 4GB and cannot be managed directly by SQL Enterprise Manager. For this reason, most organizations install SharePoint 2013 in a farm configuration and specify a separate SQL Server machine for the database server.
SharePoint Foundation 2013
SharePoint Foundation builds on the operating system and database services to add additional features, such as team sites and collaboration features. Specifically, SharePoint Foundation provides the following platform capabilities:
Storage. The primary storage mechanism for SharePoint is through content databases, which are literally SQL databases managed by SharePoint to accommodate the pages, data, and documents stored in the various sites.
Management. Configuration of settings, along with management functions, is provided via administration pages with deep configuration options.
Deployment. The deployment topology, including Web farms, physical servers, and defined roles, is provided by SharePoint Foundation.
Site model. The overall logical design consists of Web applications, site collections, and sites.
Extensibility. The ability to extend SharePoint with additional features such as Web Parts and templates, along with the overall apps model, is also provided by SharePoint Foundation.
SharePoint Foundation provides more than just these core technology services. Microsoft decided to make SharePoint Foundation a useful application out of the box, and thus SharePoint Foundation provides the following application capabilities:
Document collaboration. The core SharePoint platform provides document storage, check-in/checkout, version control, and other fundamental features for storing and managing documents. (Full capabilities require the SharePoint Standard CAL.)
Wikis and blogs. Templates like wiki templates and blog templates are provided for social collaboration features.
RSS support. The ability to consume and publish content as RSS (Really Simple Syndication) enables easier integration with content sources outside of SharePoint.
Project task management. Lightweight project management functionality is provided for simple task management. This should not be confused with Microsoft Project Server 2013, which is built on top of, and requires, the Microsoft SharePoint Server 2013 Enterprise CAL.
Contacts. The ability to manage contact information for external persons is provided as a list item template.
Calendars. The ability to manage appointments and events is available as a list item template.
E-mail integration. Core integration with an SMTP server is an important feature that provides alerts and other mail-based notification.
Integration with Office client applications. Saving to and from the Office applications, such as Word and PowerPoint, is provided by SharePoint Foundation.
Application Features
Architecturally, Microsoft SharePoint Server (Standard and Enterprise) 2013 consists of a common set of application features that support a number of areas:
Portals and publishing. SharePoint Server provides publishing templates that enable the storage and formatting of HTML content for both private and public Web sites.
Search. Capabilities for finding and surfacing content via the Search Center, cross-site search, and the Content Search Web Part is provided by a new unified search engine.
Content management. The ability to provide enterprise-scale authoring, advanced document management, and records management is something that the SharePoint Server standard CAL provides.
Business process. Most processes involve capturing data via forms and integrating with other systems. SharePoint’s forms server and line-of-business (LOB) integration feature (BCS) provide these services respectively.
Business intelligence. SharePoint 2013 dramatically improves BI features such as status indicators, PerformancePoint functionality, and Excel Services.
Composite Applications. The ability to create fast, dynamic applications, including mashups and agile applications, is provided by SharePoint Server.
Each of these is built upon the platform services and core application components of SharePoint Foundation, plus the application services components of Microsoft SharePoint Server 2013.
Service Applications
Service applications provide the features that are shared by multiple applications in Microsoft SharePoint Server 2013. What does that mean? Let’s use an example—user profiles. You may want to use the user profile feature, which provides an out-of-the-box employee directory, including basic information (e.g., name, phone number), along with some custom properties and a photograph. You may also want to create several different sites within your organization, all of which use very different URLs and have different users—for example, an Internet presence, an employee intranet site, and a collaboration portal for self-service team site use. You wouldn’t want to create and manage three separate profile databases. In this case, the user profile service can be shared across the various portals—hence it is a shared service. Specifically, the following features are provided by shared service applications in Microsoft SharePoint Server 2013:
The User Profile Service Application enables you to store and synchronize user profiles and is the foundation for My Sites, audiences, and social features.
The Search Service Application provides indexing and querying capabilities via a new engine based on underlying FAST technology.
The Managed Metadata Service Application enables you to manage a central list of terms for tagging purposes.
The Excel Services Service Application provides the ability to render Excel content and charts via a browser.
The Word Services Service Application provides the ability to render Word documents via a browser.
The Access Services Service Application provides the ability to create Access-based applications through SharePoint.
The PowerPoint Services Service Application provides the ability to render PowerPoint documents via a browser.
The Visio Services Service Application provides the ability to render Visio documents via a browser.
The PerformancePoint Services Service Application enables a number of business intelligence scenarios including charts, graphs, and drill-down reporting.
The Business Connectivity Services Service Application provides the ability to connect to databases and LOB systems outside of SharePoint.
So what exactly do service applications support? They are the middle-tier feature that supports SharePoint site collections by providing either processing functionality or data support (or both).
SharePoint 2013 does not change the service application architecture that was introduced in SharePoint 2010. For example, proxy groups are still used to define a collection of service applications that can be shared across a set of Web applications.
Sites, Site Collections, Site Templates, and Service Applications
There are fundamental concepts in SharePoint that comprise every portal, team site, Internet page, and extranet site:
Farm. A farm is simply a collection of physical or virtual servers acting as one logical SharePoint environment. The SharePoint configuration database tracks all servers in the farm and treats the farm as one logical entity.
Web application. Within a farm, you can split SharePoint into multiple Web applications. Each Web application is defined with a set of URLs, a logical partition in SharePoint, related settings, and a mapping to one or more Web sites in Internet Information Server (IIS). While not a technically perfect definition, you can think of a Web application as a URL such as http://my.intranet.com or http://sharepoint.intranet.com.
Tenant. Within a Web application, SharePoint can host many different organizations on a single farm. SharePoint can optionally provide a logical grouping just above the site collection level. This provides a tenant with the ability to configure settings for multiple site collections independent of other tenants. This is mainly used by Office 365 for hosting multiple cloud-based SharePoint deployments on a single farm.
Site collection. Within a Web application (or tenant), you can create one or more site collections. A site collection consists of a top-level site, its sub-sites, and numerous configuration settings. It is a logical unit for administration—there are settings that can be configured only at the site collection level. Each Web application can host many site collections. A site collection is the primary dividing line for SharePoint logical groupings.
Sites. A site collection can contain one or more sites. A site consists of a data repository, visual elements, administration, and almost every other core element of the functionality and experience for the user. Visually, a site is represented as one or more Web pages, lists, and Web Parts. In short, a site is a container for housing lists and libraries—along with certain configuration settings.
Lists and libraries. Within a site, lists and libraries are data repositories that can hold columns of data and/or documents. They are analogous to a database table or Excel worksheet. Lists typically store rows and columns of information (such as contacts, issues, or other related data). Libraries typically store BLOBs of data, such as documents, images, or videos. Visually, lists and libraries are represented by Web Parts, views, and input forms.
Items. The contents that lists and libraries contain are called items. Examples of items include documents, list contents such as contacts or appointments, and Web pages.
Sites and Site Collections
To explore the concepts of SharePoint, let’s start with a simple example composed of a single Web server and its logical elements (see Figure 9-1).
Figure 9-1 In SharePoint, a top-level site and its descendants are collectively referred to as a site collection
At the highest level, you have a physical server running IIS. Within IIS, you have a Web application, which maps to a URL (such as http://myportal), a port (such as 80), and an IP address (such as 192.168.1.4). Once a Web application is extended with SharePoint functionality, one or more top-level sites can be created. Each top-level site can contain one or more child sites. The collection of sites that includes a top-level site and all of its descendants down to the leaf site(s), along with the collective configuration settings, is called a site collection. This is important, since much of SharePoint administration (quotas, backup and restore, Content Types, and many others) is based on the site collection concept.
After you determine what kind of Web page elements and storage your solution requires, the next step is to plan how your sites will be implemented across site collections. A site collection is a hierarchical set of sites that can be managed together. Sites within a site collection have common features, such as shared permissions, galleries for templates, Content Types, and Web Parts, and they often share a common navigation. All sites in a site collection are (and must be) stored together in the same SQL-based content database. An intranet portal is often implemented as a site collection with the top-level Web site’s default page as the home page of the portal.
In general, we recommend that you put each of the following types of sites in separate site collections right from the start. This will help you manage site collections and content databases better in the long run.
Intranet portals
Extranet sites
Team collaboration sites
My Sites (by default, each personal site is its own site collection)
Internet sites (staging)
Internet sites (production)
Lines of businesses within a conglomerate
Document Center sites
Records Center sites
So, for example, if you were to deploy a company intranet, a corporate Internet-facing site, and a records management repository, you’d want to create three site collections right at the start. This enables you to manage the site collections individually, provide separate content databases, and more easily accommodate growth over time.
The downside of multiple site collections is that there are some features that do not work across site collections. This is important, since a large deployment of SharePoint will dictate multiple site collections. The following features do not work across site collections:
Content Types. Content Types provide the facility to define the manner in which common documents, forms, and other content are normalized in your organization.
Content Query Web Part. This Web Part aggregates information from across sites but does not work across site collections.
Workflow. When you deploy workflow, it is accessible only within the site collection in which it is deployed.
Information management and retention policies. Records management policies are set at the site collection level, forcing organizations to deploy the same policy multiple times for large enterprises.
Search. Certain features of search are configured at the site collection level.
Quotas. You should absolutely define quotas so that users are used to limited storage from Day 1. Quotas are also configured at the site collection level, which means that you will need to configure quotas separately at each top-level site.
Let’s say you decided to create two site collections to accommodate project sites: one site collection for IT and one site collection for finance. Due to the site collection limitation just described, if you wanted consistent document metadata properties on a particular document type, you’d have to deploy the Content Type twice—once for each site collection. You could also employ the Content Type hub feature, but that’s somewhat of a work-around for the fact that Content Types don’t span site collections. In addition, if you wanted to aggregate content from both site collections, the Content Query Web Part wouldn’t work; you’d need to use the Content Search Web Part instead.
Site Templates
Since a site is simply a container with some administration, some lists to back it up, and a default page for viewing its contents, how do we get a different (or consistent) look and behavior for each site in SharePoint? We use templates. Templates are simply a definition of which lists, Web Part pages, and Web Parts are to be packaged together to define a starting point for your site. Since everything is a SharePoint Foundation 2013 site in SharePoint, the template defines the look and behavior of the page(s). Table 9-1 lists the out-of-the-box templates in SharePoint 2013. In addition to the out-of-the-box templates, you can make custom templates available to users. Templates are your building blocks, allowing you to quickly create complex solutions that include custom branding and functionality.
Table 9-1 Out-of-the-Box Templates in SharePoint Foundation 2013 and Microsoft SharePoint Server 2013
A template defines what the site will look like, the lists that constitute the site initially, how publishing will work on the site, and a number of other settings. It enables a site to be created by using a predefined definition. You can think of a site as a cookie (that you eat) and a template as the cookie cutter. This typically means that unless you’ve updated the underlying site definition (which is not recommended), your site is disassociated with the template the moment the site is provisioned. The implication is that if you need to make any changes to your template later, existing sites will not update automatically.
Service Applications
In MOSS 2007, services were grouped together within a Shared Services Provider (SSP). In SharePoint 2010, this was no longer the case; the configuration of services was made more flexible by enabling single services to be configured independently. SharePoint 2013 does not change the service application architecture.
Figure 9-2 shows how service applications work in SharePoint 2013.
Figure 9-2 You can create multiple service instances if your environment needs them—for example, if you need to keep searches between your business units separate
Note
SharePoint 2013 does not support shared services over a WAN. This factor can impact design and deployment in large organizations.
Understanding SharePoint Administration
Administration in SharePoint is managed through a set of Web pages that allow both IT pros and business users to configure settings and add new content. In general, administration is broken out by role and grouped by type of task.
There are four tiers to SharePoint administration:
Central administration (which is where all global SharePoint settings are configured)
Tenant administration (which can be used in any deployment but is most commonly used with SharePoint Online)
Site collection administration (with unique settings for each site collection)
Site-level administration (with unique settings for each site)
Central Administration
With central administration, there is one central administration site per farm. It enables settings like topology, security, and application services. Figure 9-3 shows an overview of the Central Administration site.
Figure 9-3 The home page of SharePoint Central Administration provides access to core tasks you’ll need to perform to manage your farm
Who? On-premises IT administrators
Where? Farm-level
How many? One per farm
What? Used for actions like adding a new physical server to the farm or configuring Web application settings
The main page is organized into eight sections, each of which contains links to pages that help you manage your server or server farm, such as changing the server farm topology, specifying which services are running on each server, and changing settings that affect multiple servers or applications. For example, the System Settings section enables you to manage servers in the farm (see Figure 9-4).
Figure 9-4 The System Settings section of SharePoint Central Administration provides physical and logical configuration settings for your farm
Finally, the Application Management page contains links to pages that help you configure settings for Web applications and site collections that are on the farm (see Figure 9-5).
Figure 9-5 The Application Management section of SharePoint Central Administration provides ways to configure your core application components, such as Web application settings and site collection settings
Within the Application Management area is also the section called Service Applications where shared services are now configured (see Figure 9-6). This section includes administration of user profiles, My Sites, search, usage reporting, audiences, Excel Services, Business Connectivity Services, and the other service applications.
Figure 9-6 SharePoint Central Administration also gets you to a place where you can administer service applications
Tenant Administration
Tenant administration provides administration for a specific set of site collections that belong to a tenant subscription (see Figure 9-7).
Who? IT or business IT liaison (typically used with SharePoint Online)
Where: One per SharePoint Online/Office 365 subscription
How many? One per SharePoint Online tenant
What? Used for actions like creating site collections or managing service application settings in a SharePoint Online environment
Figure 9-7 The Tenant Administration page enables the Office 365 subscription administrator to configure tenant-level items, such as site collections, overall settings, and service applications
Site Collection Administration
Site collection settings provide administration for a specific site collection.
Who? Business user or IT (site collection owner)
Where: Every site collection
How many: One administration page per site collection
What? Used to configure site-collection-level configuration settings
The primary use of the Site Settings page(s) is to provide a UI where business users can manage site collection settings and the top-level sites in the site collection. By clicking the gear icon in the upper-right corner of the screen and selecting Site Settings at the top-level site, the site collection administrator can configure settings at the site collection level.
Site-Level Administration
Site settings provide administration for a specific site (see Figure 9-8).
Who? Business user or IT (site owner)
Where: Every site
How many: One administration page per site, with an extra column for site collection settings for top-level sites
What? Used for things like site configuration, creating a new list, adding users to the site, storage, site hierarchy
Figure 9-8 The administration page on a site lets a user (typically the site owner) configure site-specific items, such as site-level permissions, the lists and libraries stored within the site, and the look and feel used by the site
The primary use of the Site Settings page(s) is to provide a UI where business users can manage an individual site. This includes the site-specific permissions, the look and feel of the site, a view of out-of-the-box usage reports, and miscellaneous site settings. We recommend that business users who will be administering a site get adequate training on the Site Settings pages.
As you have seen, the various SharePoint configuration and administration settings require multiple administrators. You should carefully plan and designate which users should be administering which pieces of the SharePoint administration puzzle.
Deployment Options
In addition to administration options, another major consideration for your SharePoint rollout is your physical deployment. Even if you’re deploying in the cloud, this will mean “How many servers do I need to deploy?” This section helps you think through the answer to this question by helping you understand your options.
When considering on-premises deployment options for SharePoint, you are really considering your topology. In other words, you are determining how many servers you will deploy in your SharePoint farm and the roles they will play. In SharePoint Server 2013, how you deploy SharePoint is very flexible.
In SharePoint Server 2013, servers can have virtually any combination of services enabled. For simplicity, let’s define servers as having one of three roles:
Web Front End (WFE): the SharePoint bits with just Web rendering enabled
Application server: may include search indexing, Excel calculations, Project Server, and other features
Database server: no SharePoint-specific software is installed (only SQL Server)
Depending on need, you may have multiple servers performing each role or a single server performing multiple roles. This results in any number of physical configuration options when rolling out SharePoint. Your environment will have special requirements around server roles, authentication, DMZ, and application services, among other needs.
The following sections describe some configurations to consider. They are by no means the only ways to build your environment, but they do represent common deployment scenarios.
Zero-Server Deployment
How could you possibly deploy SharePoint without any servers at all? Quite simply, you choose a cloud deployment. By using SharePoint Online, either by itself or through Office 365, you can configure and deploy a production SharePoint offering as a pure service, rather than hosting any of your own servers.1 A cloud deployment limits certain customization options, such as full control over your farm, but does provide a fast and lower-maintenance option for using SharePoint 2013.
1. While small deployments of Office 365 and SharePoint Online require no on-premises servers, most larger deployments will use Active Directory Federation Services (ADFS) to provide single sign-on for user authentication. This requires an organization to deploy an on-premises ADFS server that can communicate with the Internet.
Single-Server Deployment
If you elect to host the servers yourself, you may start with a single server. A single server hosts all three roles (WFE, application server, and database) on a single machine. From a logical perspective, all SharePoint objects are located on this server (content sites, shared services, central administration, and databases). This is good for very small deployments, since it is fast and easy. The major downsides include scalability issues (since there is no room to grow except for expanding things like memory and processor) and availability issues (if the server goes down, SharePoint is down).
There are two ways to deploy on a single server: let SharePoint include the database for you (which will limit your total storage space) or first install SQL Server separately.
Note
Choose your deployment topology carefully. There is no direct upgrade from a stand-alone installation to a farm installation.
Two-Server Deployment
In a two-server scenario, one of the servers hosts the WFE and the application server, and the second server hosts the SQL Server database. This provides a way to manage the database separately but adds complexity without adding scalability or availability. This step adds a second tier to the deployment. In most organizations, this is the smallest deployment that is recommended for anything other than a demonstration environment or very small group.
Three-Server Deployment
By adding an additional server to the two-server deployment that acts as an additional WFE/application server, we gain scalability (by being able to service more requests) and availability (by load-balancing requests, so that if one server goes down, the system stays up and running on the other machine). The single point of failure is now the SQL machine.
Four-Server Deployment
By adding a machine to the database role and upgrading the SQL Server machine to a full cluster, we can achieve availability on both tiers of the environment. This is the smallest highly available environment, meaning that there are no single points of failure. Note that clustering is not a simple upgrade but rather a reinstall where you must move databases.
Five-Server Deployment
The next step that you should consider is to start breaking out the application services for additional performance. For example, the indexing process is very CPU-intensive and should often be put onto its own server. In a five-server deployment, the fifth server would host just an application server, primarily serving as an indexing machine. This creates a three-tier environment, with a new application server tier being added.
N-Server Deployment
The beauty of the scale-out process is that we can continue adding servers at each of the tiers, depending on the needs of the business. Do we need to serve more Web pages per second? Add more WFEs. Do we need to dedicate processor time to calculating Excel sheets? Add more application servers, specifically dedicated to Excel Services. You get the idea. Let’s say you decide that ten production machines make sense. You may then want to deploy a separate Internet farm in the DMZ and an intranet farm behind the firewall. In addition, you may want staging and testing machines so that you can adequately test new features and Web Parts. This may bring your server count to 20 servers or more. In the next section we’ll provide three specific examples: departmental, corporate intranet, and Internet-facing deployments.
Deployment Examples
The most common examples of SharePoint deployment are for departmental use, a corporate intranet, and/or an Internet-facing deployment, either as a secured extranet or a public Web site.
Departmental
A departmental solution—typically for collaboration, but it may include a team portal—will often consist of a single SharePoint server and a database server (see Figure 9-9). However, savvy departments should deploy a second SharePoint server for availability.
Figure 9-9 A departmental solution is often deployed as a single SharePoint server
Corporate Intranet
A corporate intranet—serving anywhere from hundreds to up to tens of thousands of employees—will start to incorporate dedicated application servers (see Figure 9-10). All servers are deployed within the company firewall.
Figure 9-10 Corporate intranet farms typically consist of multiple Web Front Ends, dedicated application servers, and dedicated search and index servers
Internet (Web Content Management)
A corporate Internet presence gets a bit more complicated, since you’ll not only want to have enough Web servers to serve a large number of external users, but you’ll also want an internal cluster for authoring purposes. SharePoint will then deploy all content changes from the authoring cluster to your production cluster in a one-way manner. Figure 9-11 shows an example of a SharePoint deployment in a publishing environment.
Figure 9-11 For your Internet presence, you’ll want to include servers outside your corporate firewall (for Internet user access) as well as servers inside the firewall (for employee access)
When considering the question “How do I know how many servers I will need?” the short answer for deployment is this: carefully consider your usage plan (collaboration, portal, Web content management, and so on), uptime needs, number of users, application processing demands, geographic dispersion, and budget when determining your deployment architecture.
Key Points
In SharePoint 2013, virtually everything is a site, including central administration itself.
A site is a container for lists, libraries, and settings.
Pages are items that are stored in libraries.
A site collection is a hierarchical collection of one or more sites that are managed together. All sites in a site collection must be stored together in the same content database. Some features do not work across site collections, so it’s important to plan how you use them.
A Web application is something that SharePoint manages and maps to between one and five IIS Web sites.
Administration happens at one of four levels:
Central administration (for on-premises deployments)
Tenant administration (for cloud deployments and multi-tenant deployments)
Site collection administration
Site administration
Service applications provide functionality to one or more Web applications.
Both SharePoint Foundation 2013 and SharePoint Server 2013 support shared services.
In SharePoint Server 2013, servers can have virtually any combination of services enabled; for simplicity, we typically think of servers as having one of three roles:
Web Front End (WFE)
Application server
Database server
Your server topology can contain as few as zero servers if you’re using Microsoft’s cloud-hosted option, or as many as 20 (or more!) if you have a large on-premises deployment.