SharePoint 2013 Overview and New Features
Hello, and welcome to SharePoint 2013. Microsoft has provided another great release of the SharePoint Server platform. Since the earliest version of SharePoint 2001, and Content Management Server prior to that, Microsoft has continued to expand and grow the SharePoint platform into the sophisticated information storage and retrieval system it is today.
Thank you for buying this book (or thinking about buying it, if you are browsing it in the store or online). In the next sixteen chapters, you will learn about the various new features and capabilities of SharePoint 2013 from an administration point of view, and how to use these capabilities to host your own SharePoint 2013 farm.
As with all good technical books, you can read this book cover to cover or dip into the chapters that interest you the most. I cannot make any assumptions about your previous experience with SharePoint, and so I wrote this book to appeal to a range of experience levels, starting with new administrators through to seasoned SharePoint experts. This book is an administration book, so if you are looking for development knowledge, then I recommend reading one of the development books in the SharePoint series from Apress. If you fall into the category that consists of new and upcoming SharePoint administrators, then I urge you to read all chapters in Pro SharePoint Administration 2013, starting with this chapter, where I offer an overview of SharePoint 2013. Those with extensive experience in SharePoint can also benefit from this chapter, because I cover the additions and enhancements in SharePoint 2013. Without further delay, it is time to start learning SharePoint 2013.
No, you are not seeing things, and yes, this is the topic of this section. In the previous version of SharePoint—SharePoint 2010—Microsoft liked to show off a circle diagram that described the various high-level modules in the platform. Magazine articles and books frequently included this diagram; my previous book (Pro SharePoint 2010 Administration [Apress, 2011]) was no exception. The circle diagram, or donut, as I liked to call it, described the six main areas of SharePoint 2010: Sites, Composites, Communities, Insights, Content, and Search. I could have included this diagram, except that Microsoft has now adopted a new way to describe the main modules of SharePoint 2013.
I always thought the classifications in the SharePoint 2010 donut were a little lofty, which is to say they resembled language you might expect to find in typical business literature or words used in meetings. With SharePoint 2013, Microsoft has adopted simple terms to describe better the aims of the high-level areas of the new SharePoint platform. The following summarizes each term that classifies the high-level capabilities of SharePoint 2013:
- Share—The term “sharing” has become ubiquitous with the explosion of social media. No longer do we grant access to our content, we share it instead. Throughout the various pages in SharePoint 2013, you will see share icons dotted around, which give owners of content the ability to share their content with other users. Sharing is also about empowering users to share their content across multiple devices and platforms while maintaining content in one place—SharePoint.
- Organize—Organization is about how you store your content in SharePoint. Whether you use lists or document libraries, it is about site hierarchy and structure to represent your content; it is about the metadata you assign your content to make it available to search; it is about synchronizing SharePoint content with your desktops so you can organize access to your content. Organizing is all about how you structure your data for optimum use in SharePoint 2013.
- Discover—Discovery focuses on the capability to search for content in SharePoint. Much of the functionality associated with content access in SharePoint 2013 utilizes search. Microsoft has included the search platform formerly known as FAST as the default Enterprise Search Platform in SharePoint 2013 (at no extra cost). Discovery also includes business intelligence capabilities and ability to discover information presented after applying business intelligence logic to related data.
- Build—Microsoft has made some significant changes in the way it builds applications for SharePoint 2013. The new App Model supports creation of portable and lightweight applications that host in SharePoint 2013 and other Office applications. The Microsoft App Marketplace promotes sharing of custom applications with other organizations and individuals, much like how the Marketplace for Windows Phone operates.
- Manage—SharePoint 2013 provides better capabilities to “manage” itself, whether as an on-premises SharePoint farm or as part of an Office 365 account (Microsoft’s Office in the cloud). SharePoint 2013 integrates well with Exchange and Lync 2013, and the configuration of this integration is robust and not overcomplicated to achieve. Many of the sophisticated features of SharePoint, such as business intelligence, records management, search, etc., have greater flexibility in their management and configuration.
From the previous list, you should see that Microsoft has strived to describe the core capabilities of SharePoint 2013 with labels that make sense to everyone. I know I certainly appreciate the new labels when asked to provide a simple one- to two-sentence answer to the question “What is SharePoint?”
Foundation and Server
Similar to its predecessor, SharePoint 2013 comes in two different flavors: Foundation and Server. Foundation is the core platform for SharePoint Server and is free to install and use as long as you have proper Microsoft Windows licenses. SharePoint 2013 Server builds atop of Foundation and includes many more features. Unlike Foundation, Microsoft charges for SharePoint Server licenses (more on licensing shortly), and Server provides either Standard or Enterprise license types, each offering a different set of features.
Deciding on the version of SharePoint you want usually involves determining your purpose for SharePoint. Use of Foundation is certainly compelling at zero cost (having licensed Windows Server first), but it is very limited in functionality out of the box. If you simply need to provide team collaboration and a location to upload documents, with no frills, then Foundation might be enough. In my experience, organizations that are serious about implementing an information management solution in SharePoint tend to go with SharePoint Server because it provides many attractive features that easily justify the expense. However, I have seen some very nice working solutions running on Foundation.
When deciding to implement SharePoint Server, organizations must choose whether to purchase a Standard or Enterprise version. Both versions use the same installation. Which license you activate will determine the features available for use in your farm.
Table 1-1 lists the high-level features available in Foundation, Server Standard, and Server Enterprise. Server Enterprise provides the complete suite of features, whereas Foundation and Server Standard provide a subset. Do not worry if you have not heard of many of the features in Table 1-1; I cover the majority of them throughout this book.
Table 1-1. Feature Comparison in SharePoint 2013
Of course, Table 1-1 is not exhaustive. SharePoint includes many features and to list them all would consume several pages. Table 1-1 covers the high-level features, some of which include different capabilities depending on the version and license. For example, not all capabilities of Business Connectivity Services are available in Foundation, such as use of the Secure Store Service.
Licensing
SharePoint licensing is confusing. Depending on which Microsoft representative or SharePoint vendor/provider you talk with, you may get a different answer on the cost of Standard and Enterprise licenses.
Like Windows, SharePoint requires a Client Access License (CAL) for every user or device accessing SharePoint. As I mentioned earlier, Foundation is free as long as you have Windows CALs for all your users and you are not exposing SharePoint to anonymous users on the Internet (more on this in a moment), so assume I am talking about SharePoint 2013 Server with regards to licensing, from here on. Depending on your desired functionality from SharePoint, you must buy either Standard CALs or Enterprise CALs, which have different prices. The cost per CAL differs depending on the license provider, how many CALs you buy in each purchase batch, and whether you qualify for Microsoft discounts (typically applicable only to government, not-for-profit, and charity organizations)—I did say licensing is complicated.
Prior to SharePoint 2013, you had to decide whether to purchase Enterprise CALs or Standard CALs for all users of your SharePoint farm. SharePoint Server 2013 introduces the ability to mix and match Standard and Enterprise CALs in the same farm. For example, you may have a small subset of users in your organization who require use of the Enterprise features, whereas the majority of users require only Standard features. Rather than buy all users Enterprise CALs, you can now save expense by buying Enterprise CALs for only those users who require them. By default, SharePoint Server 2013 operates in single license type mode. To enable per user license types, use the following PowerShell Cmdlets on the server running Central Administration:
- Click the Start button.
- Click All Programs and then click Microsoft SharePoint 2013 Products.
- Click SharePoint 2013 Management Shell (this loads PowerShell).
- Type in the Cmdlet: Get-SPUserLicensing at the prompt and press Enter.
- If per user licensing is disabled the Cmdlet will return False.
- To enable per user licensing, enter the following Cmdlet at the prompt and then press Enter: Enable-SPUserLicensing
- You may now map different license types to users or groups.
- Enter the following PowerShell Cmdlets to assign a license type to a set of users in an AD group (enter each Cmdlet on a new line, followed by Enter):
$a = New-SPUserLicenseMapping -SecurityGroup " AD group " -License Type Add-SPUserLicenseMapping -Mapping $a
- In the previous Cmdlets, you can provide the license type as Unlicensed, Standard, Enterprise, Project, and WACEdit.
Note Discussion of the various license types available in per user licensing is outside the scope of this book, but Standard and Enterprise correlate to those license types listed in Table 1-1.
User and device CALs work for on-premise scenarios when you know exactly how many users to support, and all your users authenticate with your SharePoint 2013 farm, but what about scenarios involving anonymous users for public-facing solutions in SharePoint? The good news is that Microsoft has finally addressed this need in SharePoint 2013. In prior versions, you had to buy a different type of license called “SharePoint for Internet Sites,” which came at a high premium because it assumed use of all Enterprise features. With SharePoint 2013, Microsoft requires you to buy only the SharePoint Server product. Of course, if you use your farm for both Internet-facing and internal-facing sites, you still need to provide CALs for users authenticating with SharePoint from within the office.
Note To understand more on SharePoint Server 2013 licensing, consult a Microsoft representative or third-party vendor of SharePoint.
Like any other server platform, SharePoint 2013 has a number of hardware and software requirements. Hardware requirements are strongly recommended by Microsoft but open for deviation, depending on your deployment plan for SharePoint. Adherence to hardware requirements ensures optimal operation and good user experience and caters to most situations involving all features enabled in the platform. On the other hand, you must meet the minimal software requirements to install and operate SharePoint 2013 (both Foundation and Server).
Hardware Requirements
When Microsoft devises the hardware requirements for SharePoint, it assumes typical scenarios that account for average user load and availability of features. Of course, what may work for one organization may not work for another—the hardware requirements to support thousands of concurrent users, utilizing search and business intelligence, with redundant hardware is very different from those of a one- or two-server farm for a small back-office deployment (see Chapter 5 for server farm planning and redundancy). Fortunately, Microsoft published its hardware requirements for SharePoint 2013 to account for a variety of scenarios, as shown in Table 1-2.
Table 1-2. SharePoint Web and Application Server Minimum Hardware Requirements
I remember when Microsoft first released the beta version of SharePoint 2013 and published the hardware requirements for development farms. I was shocked to read that my development server would need 24GB of RAM, especially since I typically use close to this amount of RAM for complete virtual server host. However, with further clarification, you can see from Table 1-2 that 8GB of RAM could work for most development scenarios, but it assumes the absence of Visual Studio (an application that is heavy on RAM) and installation of a minimum number of services.
Notice the last line in Table 1-2, which caters to staging and production environments. These deployments host SQL Server separately and assume separate SharePoint application and web servers (three-tier). To cater to typical user load on a single web server, 12GB of RAM with a four-core CPU should provide enough horsepower. The beauty of SharePoint is that it scales, so if you overload one server with concurrent user requests, then you may add additional servers to the farm and load balance requests. Each new web or application server added to the farm requires the same minimum hardware specifications as listed in Table 1-2. Just as with SharePoint 2010, SharePoint 2013 requires 64-bit hardware and operating system to operate.
Note See the following information for SharePoint 2013 capacity planning: http://technet.microsoft.com/en-us/library/Cc261700.aspx.
I covered the hardware requirements for SharePoint web and application servers in the previous paragraphs. SQL Server also requires minimum hardware requirements. The requirements shown in Table 1-3 assume that you dedicate SQL Server to one SharePoint 2013 farm instance. SQL Server supports multiple instances and can host databases for any number of other applications, which could exceed the capacity of your SQL Server hardware.
Table 1-3. SQL Server Minimum Hardware Requirements for SharePoint 2013
Unlike with hardware requirements, SharePoint 2013 is very strict on the minimum level of software it requires to install and operate. Since SharePoint 2010, servers and host operating systems must be 64-bit. SharePoint 2013 no longer supports SQL Server prior to 2008 R2. SharePoint requires at least Windows Server 2008, as shown in Table 1-4.
Table 1-4. Minimum Software Requirements for SharePoint 2013
I cover SharePoint 2013 installation in Chapter 2. Installation consists of running a prerequisite installer, which installs any prerequisite software and configures server roles in Windows Server.
Before jumping into the new and exciting changes that SharePoint 2013 brings, I wanted to mention environment type planning briefly. It is not my intent to dive deep into the topic of planning for development, staging, and production environments. Many good books exist on this topic that explore the differences among each environment type and considerations of each. However, before I turn you into an experienced SharePoint administrator (if you are not already) through your reading the pages in this book, I wanted to brief you on this topic before you start installing and configuring SharePoint.
Development and production SharePoint farms behave very differently. Typically, a development environment is looser with security constraints, has all or most features enabled, and is seldom optimized. Compare this to a production farm, which has limited administration access (SharePoint administrators only), has only those features enabled to provide a working solution, and undergoes rigorous performance testing and configuration tweaking.
In Chapter 2, I shall walk you through the process of installing SharePoint 2013 Server. I discuss use of the Farm Configuration Wizard (not to be confused with the Installation Configuration Wizard), which is a helpful automated process for provisioning services and service applications. Bear in mind that this wizard is strictly for development and non-production environments. The Farm Configuration Wizard makes assumptions about service databases, default service application configuration, allocation of application pools, and default configuration as a whole. The preferred approach to standing up a production environment is to use SharePoint PowerShell Cmdlets (see Chapter 3) to script a minimal footprint installation and configuration. This requires intricate working knowledge of SharePoint 2013 configuration and the use of many PowerShell Cmdlets. I touch on many of these Cmdlets throughout this book and guide you in configuration for best practice. However, after reading this book, do consider further research on best practices for advanced SharePoint 2013 deployment.
User Interface and User Experience Changes
The first thing you will notice when opening SharePoint 2013 is the new user interface and experience changes. Compare the screenshot from SharePoint 2010 (Figure 1-1) to that of SharePoint 2013 (Figure 1-2). The versions have similar page layouts and high-level functional areas, with links to various operations. SharePoint 2013 now adopts the “Windows 8” theme (formally known as “Metro”). I cover SharePoint 2013 branding in detail in Chapter 16, but as you read this book, you will begin to appreciate the new branding.
Figure 1-1. Central Administration in SharePoint Server 2010
Figure 1-2. Central Administration in SharePoint Server 2013
Although not immediately obvious from the previous screenshots, one change apparent to anyone using SharePoint 2013 after SharePoint 2010 is the change to the Site Actions menu. In SharePoint 2010, the Site Actions menu resided in the top left corner and provided access to view all site content and settings for SharePoint sites. SharePoint 2013 replaces the Site Actions menu with a gear icon (or cog, if you prefer), which resides in the top right corner. SharePoint 2013 clusters the pervasive operations in the top right, as the go-to place for users to administer their site and access personal settings.
SharePoint 2010 introduced dialog boxes to limit the number of page refreshes inherent in SharePoint 2007. Dialogs certainly made working with SharePoint better, but they added to the complexity of the user interface. SharePoint 2013 minimizes dialog boxes—a number of the settings pages revert to regular pages. Microsoft has addressed the page refresh issue with in-place refresh.
Open a regular team site in SharePoint 2013. As you navigate around the site, you should notice that the page URL in the browser address bar refers to the same file: start.aspx. The following is an example of the home page: http://sp2013/_layouts/15/start.aspx#/SitePages/Home.aspx. When navigating from page to page, the browser stays on the start.aspx page and the value after the hash symbol in the URL tells the browser to load new page content via JavaScript. This effectively gives the user the impression that page refreshes occur snappily without the redraw effect that you may typically expect with general web browsing. The idea is to give the user a feeling of a rich application, rather than a view of web pages. In development circles, this out-bound JavaScript rendering of page content is referred to as AJAX.
Architectural Changes
If you are familiar with SharePoint 2010 architecture, from a high-level view, you might think that SharePoint 2013 architecture is the same but with a UI facelift. In fact, much of the architecture in SharePoint 2013 is identical to that of SharePoint 2010, but with a number of improvements and additions. I shall cover the majority of enhancements in this section, although the list is not exhaustive. I could write a chapter on each of these architectural enhancement areas, and I recommend further reading on these in addition to my synopsis in this chapter.
Microsoft SQL Server 2012 contains many new enhancements to support SharePoint 2013 business intelligence (BI) features. SQL Server 2012 is also cloud-ready. This is not to say that your experience of SharePoint 2013 is sub-par on SQL Server 2008 R2, just that some of the more advanced BI features require the latest version of SQL Server.
Part of the new enhancements to SharePoint databases includes support for Shredded Storage, which I shall discuss in the next section. In addition, Microsoft has optimized SharePoint database schema to optimize input/output (IO) for large lists and document libraries. All SharePoint databases comply with Windows Azure criteria, which I assume is to support SharePoint in the cloud as part of Office 365.
Shredded Storage
Shredded Storage is new to SharePoint 2013 and a regularly talked-about topic in the SharePoint community. Shredded Storage reduces the amount of data flowing to and from SQL Server from SharePoint servers by sending only deltas—that is, changed data only.
Shredded Storage really comes into its own when saving and loading large documents (BLOBs) to and from the database, because instead of transmitting large documents (megabytes in size) SharePoint 2013 now sends only the incremental changes. Think about how you collaborate with peers on document creation; most of the time you might make small changes that you regularly save back to SharePoint. Shredded Storage optimizes this process for faster and more responsive load and save times.
In an effort to use industry standards (or to at least publish standards for use by others), Microsoft built Shredded Storage using the MS-FSSHTTP standard protocol: Microsoft File Sync via SOAP over HTTP. This protocol handles synchronization of small file changes (delta) via SOAP (Simple Object Access Protocol) via HTTP (Hyper Text Transmission Protocol)—it is a bit of a mouthful!
With MS-FSSHTTP, users can see the benefit in working with files stored in SharePoint and work together with peers on the same document, because MS-FSSHTTP manages synchronization of independent changes to the same file by different users. Some of the benefits of Shredded Storage are
- Reduced network bandwidth
- Significantly reduced database size
- Faster read and save times
- Ability to read cached documents
- Ability to start work on a document before the entire file has downloaded
- Background saving of changes, giving the impression that documents save immediately
Shredded Storage is not limited to Office-type documents. SharePoint 2013 and Shredded Storage support any file type. SharePoint utilizes a feature of Windows called Remote Differential Compression (RDC) to ascertain deltas in binary files.
Note When upgrading from SharePoint 2010 to SharePoint 2013, existing content does not use Shredded Storage; it is used only when modifying an existing file or adding a new file to SharePoint 2013. Thus upgrading from SharePoint 2010 does not reduce the size of content databases. For more information on Shredded Storage, read http://blogs.technet.com/b/wbaer/archive/2012/11/12/introduction-to-shredded-storage-in-sharepoint-2013.aspx.
Request Management
Request Management assists in directing incoming web requests from client web browsers to servers capable of servicing the requests. In essence, Request Management is a rules-based engine that directs incoming client requests to SharePoint servers in order to serve users quickly and appropriately.
Request Management exists in SharePoint 2013 as a service called SharePoint Foundation Web Application Service. The presence of the word “Foundation” should tip you off that Request Management operates in all versions of SharePoint 2013, including Foundation, as well as Server. Each web-front-end server in a SharePoint 2013 farm runs the service and can therefore play a part in Request Management.
Request Management relies on a series of rules to determine how to route incoming web requests. You can add new rules or change the provided rules to influence how different servers in your farm respond to different requests. Furthermore, you can configure Request Management rules to deny certain requests to your farm and manage load-intensive web requests with throttle rules.
Request Management assumes the existence of multiple servers to satisfy web requests (Request Management has little purpose in a single-server farm). I cover Request Management in detail in Chapter 5.
“Workflow” is a common term given to any process flow that involves work. In business, we use workflow all day long—as part of company policy, in the way we do our jobs, and in the way we use information systems to handle data. Automated workflow is the delegation of certain business processes to computers and systems such that we can alleviate repetitive and mundane tasks normally assigned to humans.
Microsoft introduced Windows Workflow some time back before the release of SharePoint 2007. In fact, Windows Workflow is not a SharePoint-based technology; Microsoft released the Windows Workflow Framework with the early version of .NET 3.0. Since SharePoint 2007, Microsoft has embraced the use of automated workflow in the platform to handle document approval, language content translation, and task assignment, and as part of a number of other areas in SharePoint. Because Windows Workflow exists as a framework, SharePoint has always supported custom workflows, implemented in either SharePoint Designer or Visual Studio. As the workflow framework has evolved, SharePoint has continued to support it in SharePoint 2010 and now as part of SharePoint 2013.
Automated workflow can consume system resources. Each running workflow relies on the framework to track its status, interact with users with delegated tasks, integrate with e-mail and SharePoint, and utilize with data. As a result, some complicated workflows (there is no end to how complicated you can make custom workflows) consume RAM and processor resources in SharePoint. Microsoft has addressed this issue with a completely redesigned distributable workflow system, which Microsoft hosts in the cloud as part of its Azure Cloud Services.
Figure 1-3 shows the new workflow architecture integrated into SharePoint 2013. The new architecture supports both legacy workflow (“Workflow 2010”) and the new distributed workflow infrastructure in Azure. The new architecture abstracts the workflow plumbing and allows you to create new custom workflows in SharePoint Designer and Visual Studio, as before. The SharePoint Object Model continues to provide access to the SharePoint infrastructure so you can design custom workflow around data and events with SharePoint sites. Within the SharePoint 2013 object model is the Workflow Services Manager, which handles the execution of custom workflow, either via the legacy Workflow 2010 engine, by making Representational State Transfer (REST) calls, or hosted Workflow in Azure (Windows Azure Workflow).
Figure 1-3. New workflow architecture
Windows Azure Workflow (WAW) does not integrate with SharePoint 2013 out of the box. In Chapter 12, I cover the steps to configure WAW and demonstrate distributed workflow.
Note See http://msdn.microsoft.com/en-us/library/jj163177.aspx for more information on the new workflow model in SharePoint 2013.
Separation of Office Web Applications
Office Web Applications (OWA) complement the full suite of Office applications by allowing users to open Office documents in a web browser. Office Web Apps support opening Word documents, Excel documents, PowerPoint presentations, and OneNote notebooks, either from SharePoint document libraries or via SkyDrive. The purpose of OWA is to provide the basic editing capabilities of Word, Excel, PowerPoint, and OneNote without users having to install full Office applications.
Prior to SharePoint 2013, OWA consisted of an installable package (binaries), which hosted OWA services in SharePoint 2010. Installation was separate from the main SharePoint installation, and at times complicated to configure. With the release of SharePoint 2013, OWA now consists of a separate server application, which you must install on a separate server to that of SharePoint—OWA will not let you install it on a SharePoint server. Part of the reason to separate OWA from SharePoint is because OWA consumes a large amount of RAM and processor on the server, which affected operation of SharePoint when multiple users were editing documents in OWA applications. Another likely reason for the separation is that Microsoft now provides OWA services via Office 365, its Office in the cloud. To support the many users who might use OWA and SharePoint, it makes sense to provide OWA as a stand-alone product.
Like much of SharePoint 2013, Office Web Apps have a number of new features as part of the new release. Table 1-5 summarizes the enhancements and changes in OWA.
Table 1-5. Changes in Office Web Apps
| Change/Enhancement | Description |
|---|---|
| Change Tracking | Users can view track changes in Word documents opened in OWA. |
| Co-authoring | Previously, only Excel and OneNote supported co-authoring in OWA. Now Word and PowerPoint join the fold. |
| Comments | Users can view, add, and reply to comments added to Word and PowerPoint documents in OWA. |
| Embedding | OWA now supports embedding Word, Excel, and PowerPoint web apps in other applications. |
| Ink Support | Enables users to view Word and OneNote files that contain Ink. |
| Installation | OWA no longer installs as part of SharePoint. Instead, install and deploy OWA and a separate server and then configure SharePoint 2013 to open Office documents via the OWA Server. |
| Licensing | Editing of Office documents in OWA requires that users have the appropriate license. If users have no license or you have not configured SharePoint user licensing, then users can only view and not edit Office via OWA. |
| Quick Preview | When integrated with SharePoint 2013, users can hover over search results and OWA will display previews of documents listed in the search results. |
| Share by Link | Users may send a URL to a document and allow other users to open the document in OWA. |
Note I cover integration of an existing OWA Server with SharePoint 2013 in Chapter 14. For additional information, consult the following article: http://technet.microsoft.com/en-us/library/ff431685.aspx.
Prior to SharePoint 2013, SharePoint provided per-server caching. Each SharePoint server held items in its memory cache until either someone removed the item from the cache or the cache time expired and the cache infrastructure removed it. SharePoint itself would use its cache, and developers of custom solutions could make good use of the cache to speed up access to data. If an item exists in memory cache, SharePoint has no need to fetch the data item from a SQL database or other data repository.
The problem with per-server caching is that load balanced servers cannot take full advantage of caching to increase performance. Different web servers in a SharePoint farm may service two identical sequential web requests. If the first server queries the database for an item and then loads the item into cached memory, the cached item is good only as long as subsequent requests query the same server. SharePoint 2013 includes the Distributed Cache, which alleviates this problem with a common cache for all servers in the farm.
The SharePoint 2013 Distributed Cache Service (DCS) builds on the Microsoft App Fabric 1.1 caching model. A number of SharePoint components utilize DCS to maintain cached data across all servers in the farm; these components include elements of the user newsfeeds, search, and authentication.
Note For more information on App Fabric Caching, consult the following article: http://msdn.microsoft.com/en-us/library/ff383731%28v=azure.10%29.aspx.
When installing SharePoint 2013, the installation process installs a version of the App Fabric Caching model. This is important to note, because SharePoint 2013 requires the precise version of App Fabric it installs, and not necessarily a later or earlier version of App Fabric available from Microsoft. DCS relies on several open TCP ports to communicate across server boundaries. If all SharePoint servers communicate on the same network, behind firewalls, then you have no need to open these ports on your firewalls. However, if you have a distributed SharePoint farm, then make sure you open the TCP ports 22233–22236. Table 1-6 lists the SharePoint 2013 components that rely on DCS, and in what capacity.
Table 1-6. SharePoint 2013 Use of the Distributed Cache Service
| Component | Details |
|---|---|
| Feeds | SharePoint stores activities and events in DCS for My Site newsfeeds. SharePoint leverages the cache mainly for activities you follow and for displaying the Everyone feed (see Chapter 6 for more information on My Site newsfeeds). |
| Logon Tokens | SharePoint 2013 federates authentication by using a Secure Token Service, which identifies authenticated users with signed SAML tokens (Security Assertion Markup Language). Each signed SAML token (which is an encrypted and signed XML file) represents a user identity that authenticated and has permitted access to SharePoint (see more information in Chapter 8). This token is the “Logon Token” for the user. SharePoint continuously performs security checks as users access parts of the platform, which is why SharePoint 2013 requires access to each user’s logon token to ensure that the user is still authenticated (i.e., their session has not expired) and is authorized. SharePoint stores logon tokens in DCS, so every server in the farm can access the token without requiring the user to re-authenticate on each server. |
| Search | The Content Search Web Part stores queried data in DCS so that multiple SharePoint web-front-end servers can optimally render pages without repeated search queries. (See Chapter 15 for more information on search and the Content Search Web Part). |
The App Fabric Cache operates as a Windows service on each SharePoint server. However, you should never make configuration changes to App Fabric Caching directly, and instead use SharePoint 2013 Central Administration. Later in this book, you shall see examples of how to start, stop, and configure services running within the SharePoint 2013 farm. The Distributed Cache Service is one of these services. Ideally, you should never have to play with the DCS settings, but on occasion, if DCS should fail (authentication, My Site newsfeeds, and Content Search Web Parts will break) you may have to look to the DCS settings to get to the root of the problem.
Note For more details on the Distributed Cache Service, see http://technet.microsoft.com/en-us/library/jj219613/8v=office.159.aspx.
Service Application Changes
SharePoint 2010 introduced the new Service Application Architecture, which replaced the legacy Shared Service Provider (SSP) in SharePoint 2007. SharePoint 2013 continues to use the Service Application Architecture, with some changes to existing service applications and some new service applications added. I shall now briefly recap the Service Application Architecture.
Service Application Architecture Overview
SharePoint is a highly scalable platform, which Microsoft made possible with its distributed architecture. A SharePoint farm (2010 and 2013) can contain any number of web-front-end servers to handle user web requests and any number of application servers to distribute back-end services, such as search, business intelligence, managed metadata, etc. Prior to SharePoint 2010, SharePoint 2007 only allowed scaling of web-front-end servers and limited services to a single server as part of the SSP. Since SharePoint 2010, the Service Application model implements a Software-As-A-Service (SAAS)design, such that the platform makes a variety of services available across a SharePoint farm, and each service may reside on any SharePoint server—this is known as distributed services. Furthermore, because of the distributed nature of the design, multiple SharePoint farms may share the use of services from other SharePoint farms.
Each service provided by SharePoint 2013 operates on one or more servers in the farm. I say one or more because a SharePoint farm may require only one instance of a running service to perform some work, but running the service on multiple servers ensures redundancy and allows for load balancing. Take PerformancePoint as an example. PerformancePoint runs as a physical SharePoint service on an application server in your farm. If you enable this service, you can take advantage of the business intelligence capabilities PerformancePoint has to offer. However, enabling the PerformancePoint Service on one or many application servers in your farm is not enough to distribute this service as available across the farm.
Each distributed SharePoint Service exposes a WCF (Windows Communication Foundation) end point, which is a fancy way of saying that the service exposes itself as a web service. The PerformancePoint Service exposes an end point, which any WCF client may connect to utilize PerformancePoint business intelligence. Management and configuration of the service require a Managed Application. Managed Applications are similar to regular web applications in SharePoint (see Chapter 2), but instead of hosting site collections, they associate with services on the server to allow configuration.
Continuing to use the PerformancePoint Service as an example, if you open SharePoint 2013 Central Administration, click the link to manage service applications and then click the PerformancePoint Service Application (assuming you have it installed), the PerformancePoint Service Application renders pages in your browser to configure the working parameters of the PerformancePoint Service.
Typically, each SharePoint service and service application has one or many associated databases to maintain configuration settings and working data. These three components represent the server side of a distributed service.
A proxy is required for servers in the SharePoint farm to communicate with SharePoint Services hosted on a different server. The proxy is a WCF client that communicates directly with the distributed WCF service end point and enables use of the remote functionality on the local server in which the proxy resides. Irrespective of where the service resides, each server looking to consume a service requires a locally installed proxy. In a single-application SharePoint farm, each service and associated service application also has a local proxy talking with the service on the same server.
In conclusion, SharePoint 2013 provides a number of service applications each performing a role. Examples include Business Connectivity Services, Search Service, PerformancePoint Services, Excel Services, Managed Metadata Service, etc. Each service application consists of the following components:
- Configuration databases
- The WCF service with exposed end point
- A Managed Service Application (IIS application) that provides management and configuration
- A proxy to communicate with the service end point.
New Service Applications
With the Service Application Architecture recap out of the way, I shall now discuss some of the service applications that Microsoft added to SharePoint 2013. SharePoint 2013 includes three new service applications, as follows:
- Machine Translation Service
- Work Management
- App Management
Note The Machine Translation Service is the only one of the three service applications that you may distribute cross-farm. The Work Management and App Management services work only within their respective farms.
The Machine Translation Service provides language translation services for sites, pages, and managed term sets in SharePoint, by using Microsoft Bing to perform the translation work. This managed service relies on a handful of timer jobs to process requested translation tasks by sending content to Bing and replacing foreign-language content with translated data.
The Work Management Service aggregates user tasks to provide a centralized task list. This service aggregates tasks from Exchange, Project Server, and SharePoint 2013 and allows users to manage centrally all their tasks via their My Site.
Note For more information on configuring synchronization with the Work Management Service, please consult the following article: http://technet.microsoft.com/en-us/library/jj554516.aspx.
The App Management Service is responsible for hosting new SharePoint apps, either custom-developed or installed from the App Marketplace. Everything is an app in SharePoint 2013; Microsoft refers to lists and libraries as apps—the task list is a particular type of list app that handles storage of tasks. When adding a new list or library in SharePoint 2013 you should see the Add an App menu item, under the Settings menu (gear icon); see Figure 1-4.
Figure 1-4. Add an app in the Settings menu
Apps are not just the new terminology for lists and libraries in SharePoint 2013. Apps are modules of functionality that you may host in SharePoint and/or other Office applications. With the mass adoption of Office 365 and hosting business SharePoint in the cloud, apps allow development of lightweight functionality, which you may deploy to O365, whereas full-blown farm features may deploy only to on-premise SharePoint.
Figure 1-5 shows a screenshot of the App Marketplace (App Store) within my SharePoint team site. The App Store itself resides with Microsoft, but SharePoint 2013 does a great job of integrating it with the platform as if it is part of your site. If you have permissions to install apps in your site, feel free to download some of the apps in the store and install them.
Figure 1-5. The App Store for SharePoint apps
To host apps inside your SharePoint sites, you must:
- Enable the App Managed Service in SharePoint.
- Enable the Microsoft SharePoint Foundation Subscription Settings Service.
- Create a Managed Service Application for the App Managed Service.
- Create a Managed Service Application for the Subscription Settings Service.
- Create proxies for both of the previous Managed Application Services.
- Create an Apps Catalog.
To start the App Management and Subscription Settings services, open Central Administration and click the link for “Services on Server”; from here you can start each service, if not already started. To create the managed service applications and proxies, first open a PowerShell window with the following steps:
- Click the Start button.
- Click All Programs and then click Microsoft SharePoint 2013 Products.
- Click SharePoint 2013 Management Shell (this loads PowerShell).
Next, execute each of the following PowerShell Cmdlets (followed by Enter after each):
$appPool= Get-SPServiceApplicationPool -Identity " Name of Managed Service Account "
$app = New-SPSubscriptionSettingsServiceApplication -ApplicationPool $appPool '
-Name SettingsServiceApp -DatabaseName SettingServiceDB
$proxy = New-SPSubscriptionSettingsServiceApplicationProxy -ServiceApplication $app
$appServ = New-SPAppManagementServiceApplication -ApplicationPool $appPool '
-Name AppManServiceApp -DatabaseName AppManServiceDB
$appProxy = New-SPAppManagementServiceApplicationProxy -ServiceApplication $appServ
To host apps in SharePoint, you must create a Managed App Catalog for each web application. If you have multiple web applications for your sites then you must create a Managed App Catalog for each. Navigate to Central Admin and then click the Manage App Catalog link under the App Management heading.
Figure 1-6 shows the administration page to configure a new App Catalog for a selected web application. To manage an existing App Catalog, type the URL in the text box and then click the OK button.
Figure 1-6. Manage App Catalog in Central Administration
Note For more information on the SharePoint App Model and App development, please consult the following article: http://msdn.microsoft.com/en-us/library/jj164084.aspx.
Depreciated and Changed Service Applications
With any new version of SharePoint, you can expect Microsoft to depreciate or change certain features. This section discusses depreciated and changed Managed Service Applications.
Microsoft implemented a new version of the Search Service Application, from the ground up. SharePoint 2010 offered FAST as an alternative Enterprise Search Platform at additional cost while still providing SharePoint Enterprise Search. SharePoint 2013 includes FAST as the default Enterprise Search offering, which meant redesigning the Search Service Application. I cover search in much detail in Chapter 15.
SharePoint 2013 offers a more robust version of the Managed Metadata Service (MMS) Application. MMS now supports term properties; you can provide site navigation using terms in the term store and pin terms to reduce the number of duplicate terms in the store. Microsoft has also improved how users can create terms and term sets. See Chapter 9 for details on the Managed Metadata Service.
Web Analytics no longer exists as its own Managed Service Application; Microsoft rolled this functionality into the SharePoint 2013 search platform.
As mentioned earlier in this chapter, Office Web Apps is no longer a service application. OWA now exists as a stand-alone server application.
SharePoint 2013 brings a new improved User Profile Service (UPS). If you have experience with UPS in SharePoint 2010, you may remember the vast number of configuration issues and errors associated with UPS provisioning and setting up directory synchronization. Each hotfix and service pack solved some issues with UPS and introduced others. Fortunately, the User Profile Service and synchronization capabilities of SharePoint 2013 are more robust. UPS synchronization still uses Forefront Identity Management (FIM) services as the core for user profile synchronization, but SharePoint 2013 also provides an additional synchronization feature that allows one-way synchronization with Active Directory, much like that provided in SharePoint 2007. This additional synchronization feature allows for the more common configuration of one-way synchronization with Active Directory without the overhead of FIM.
Microsoft built a new version of Access Services but kept the original version from SharePoint 2010, which it calls Access Services 2010. I would expect that the legacy version might disappear with the next release of SharePoint.
SharePoint 2013 includes a new PowerPoint Automation Service, which is similar to the Word Automation Service, for translating PowerPoint presentations into other formats, such as HTML and PDF. PowerPoint Automation Services is not strictly a Managed Application Service, because it consists of only the service, meaning there is no configuration aspect to this feature.
Finally, the Business Connectivity Services Managed Service Application has undergone some enhancements. Namely, BCS now supports Open Data (OData) and JavaScript Object Notation (JSON) protocols for communicating with external sources. BCS also adds the very much anticipated event receivers for external data, such that custom code can detect changes to external data. Other changes include support for the new SharePoint Apps Model and a number of performance enhancements for external lists and external content types.
Security Changes
Not much has changed in the security features of SharePoint 2013. Similar to SharePoint 2010, SharePoint 2013 supports Claims-Based-Authentication, using federated authentication (see Chapter 8 for more information on Claims-Based-Authentication). Earlier in this chapter, I touched on how the Distributed Cache Service maintains copies of logon tokens—signed and encrypted XML files representing authenticated user identities. One notable change is that SharePoint 2013 requires all web applications created from Central Administration to use Claims-Based-Authentication. It is still possible to create web applications that use Classic Mode Authentication, via PowerShell, but Microsoft no longer supports this method of authentication, and you can expect Microsoft to retire it completely in later releases of SharePoint.
With the inclusion of the new App Model, SharePoint now supports the OAUTH authorization protocol. OAUTH provides a method for clients to access server resources on behalf of a resource owner (such as a different client or an end user). It also provides a process for end users to authorize third-party access to their server resources without sharing their credentials (typically, a username and password pair).
OAUTH enables users to authorize SharePoint 2013 to provide tokens instead of credentials (for example, username and password) to their data hosted by SharePoint 2013. Each token grants access to a specific site (for example, a SharePoint document repository) for specific resources (for example, documents from a folder) and for a defined duration (for example, 30 minutes). This enables users to grant a third-party site access to information that is stored with SharePoint without sharing their username and password and without sharing all the data that they have on SharePoint. OAUTH makes it possible to run apps developed and hosted by other people inside the context of your SharePoint site, such that the app can only access certain resources for a definite length of time.
Summary
I hope that this chapter has given you a taste of what to expect in SharePoint 2013. I also hope that I have given you a sense of what to expect in the remaining fifteen chapters in this book. It was my goal to give you an overview of the SharePoint platform, from an administrative perspective, and to dive into many of the new features and changes with this new release. I deliberately stayed away from lengthy descriptions of SharePoint from a business standpoint and the sort of information that I would provide business users when asked of the end-user purpose of SharePoint 2013. Instead, I hope I provided you with enough insight into SharePoint 2013 as a technical person, and set the stage for the administration theme of this book.
In this chapter, I covered the different versions of SharePoint 2013—Foundation and Server—and spent some time detailing the license differences between SharePoint 2013 Server Standard and Enterprise.
I furnished you with the hardware and software prerequisites, so that you start on the right track with your installation and deployment.
I was excited to cover the new architecture changes that SharePoint 2013 brings over its predecessor and to cover additions and changes to the Managed Service Application infrastructure. I included details about the new App Model and a brief note on the use of the OAUTH authorization protocol for apps.
This chapter was a short one, and it was my intention to use it as a springboard for the rest of the book. Do not worry if some of the topics mentioned in this chapter caught you by surprise. I cover many of the topics in detail throughout this book. Where possible, I provide you with reference links to topics outside the scope of this book. With the introduction out of the way, now it is time to begin Chapter 2, where you will learn how to install SharePoint 2013.