SharePoint 2013 Changes and Enhancements from SharePoint 2010

First thing I would like to say that SharePoint 2013 Rocks!!!  Last week [24^th Sept to 28 Sept 2012] I have attended SharePoint 2013 IT Pro training at Microsoft Hyderabad campus. Based on the training, training material and slides I am writing this first blog on SharePoint 2013. This blog will give you the overall picture of changes & modification done in SharePoint 2013 from the SharePoint 2010.

There is drastic change in the user interface of SharePoint 2013 in comparison with SharePoint 2010. I found SharePoint 2013 user interface more interactive and more usable. There are lots of platform level changes done in SharePoint 2013. 

Below are the points where architectural changes & modification has been done in SharePoint 2013 in comparison with SharePoint 2010

• Shredded Storage
• SQL Improvements
• Cache Service
• Request Management
• Service Applications
• Office Web Apps
• Analytics
• Social Changes
• SharePoint 2013 Farm Considerations

Let me brief you about each bullet points of changes/enhancement done in SharePoint 2013:-

Shredded Storage

The goal is to make changes equal to the size of the change, not size of the file

How It Works in SharePoint 2010:

When a file is updated via Cobalt, only the bits that have changed are sent over the wire from the client to the SharePoint WFE.  However, because SharePoint lacks the concept of incremental updates to SQL, so the system was forced to:

a)    pull the entire file to the WFE

b)    merge the changes into it

c)    write the entire file back to SQL

How It Works in SharePoint 2013:

Now in SharePoint 2013 the file is break into pieces and store that in SQL

On update of the file, only the shredded blobs that correspond to the updated bits are touched and stored in SQL, so that means the entire file saved and after the modification only the changes are stored in SQL, so it avoid round tripping entire files to the WFE and back.

SQL Improvements

• Microsoft has reduced scenarios that might invoke full table scans. There have been lots of improvements around finding docs for link fix-up and alert handling
• Reduced data redundancy for some features
• Using advanced indexing features provided by SQL 2008 R2
• Changes in architecture to support wide lists, i.e. lists where a single item spans multiple rows in the database to hold the data

Cache Service

There is a new distributed cache service in SharePoint 2013 based on Windows Server AppFabric Distributed Caching, It is used in features like authentication token caching and My Site social feeds. SharePoint 2013 uses caching features that cloud-based cache (Windows Azure Cache) does not support at this time, so only local cache hosts can be used

SharePoint ONLY supports the version of caching that it ships – you cannot independently upgrade it.

The config DB keeps track of which machines in the farm are running the cache service, It is all provisioned by SharePoint setup

A new Windows service – the Distributed Cache service – is installed on each server in the farm when SharePoint is installed

Request Management

The purpose of the Request Management feature is to give SharePoint knowledge of and more control over incoming requests, Having knowledge over the nature of incoming requests – for example, the user agent, requested URL, or source IP – allows SharePoint to customize the response to each request, RM is applied per web app, just like throttling is done in SharePoint 2010.

RM is turned off by default

RM – Goals (you can think of RM as replacement of NLB):

RM can route to WFEs with better health, keeping low-health WFEs alive

RM can identify harmful requests and deny them immediately

RM can prioritize requests by throttling lower-priority ones (bots) to serve higher-priority ones (end-users)

RM can send all requests of specific type, like search for example, to specific machines

Isolated traffic can help troubleshoot errors on one machine

RM can send heavy requests to more powerful WFEs

RM Components

RM Routing and Pools

Routing rules route requests and are associated with MachinePools, MachinePools contain servers, servers use weights for routing – static weights and health weights

Static weights are constant for WFEs; health weights change dynamically based on health scores

RM Routing Rules

Routing to a server in a MachinePool is based on matching a routing rule

Routing rules are placed in ExecutionGroups

These are numbered 0 to 2, with 0 the default

Rules are evaluated in each ExecutionGroup

As soon as a match is found no more ExecutionGroups are evaluated

All machines from pools that match any routing rules are union’ed together to determine possible target servers

This means that you create your most important rules in ExecutionGroup 0

There are some important caveats to remember about routing rules

If no rules are matched, then the request will get routed to any available routing target

If you want to route to a subset of machines, make a rule with no criteria and specify the subset of machines you want to routed to

RM – Why Not Throttling?

SharePoint 2010 has throttling but there is room for improvement

Uses a health score system in which WFEs attach their health info to all responses

The drawbacks from this approach were:

It was the clients’ responsibility to honor the health scores

It did not preclude WFE failure

Clients could be shown server busy messages from a poor-health WFE when other better-health WFEs were available

RM Throttling Rules

Routing rules process requests; throttling rules stop requests

It’s much like throttling in SharePoint 2010, only more sophisticated

You create criteria for the throttling rule, and if the criteria is met the request is throttled

The process and PowerShell for creating throttling rules is very similar to routing rules

Criteria's You Can Use for Routing and Throttling

Rules can match on these properties:

Url, UrlReferrer, UserAgent, Host, IP, HttpMethod, SoapAction, CustomHeader,

You can evaluate values using these methods:

StartsWith, EndsWith, Equals, RegEx

RM Routing Weights

RM uses static weights and health weights

Static weights are associated with WFEs so certain ones will always be favored when selecting.

This gives added weight to more powerful WFEs and less to weaker machines

Health weights are used to even out load and keep “sick” WFEs going

Health scores run from 0 to 10 where 0 is the healthiest and therefore will get the most requests; this score is used to derive the health weight

WFEs start with a healthy weight; the Policy Engine health rule updates health weights dynamically – you cannot change it manually

Service Applications

There are a few new service applications in SharePoint 2013:

App Management Service:  allows you to install SharePoint apps from the Office Marketplace or the App Catalog

SharePoint Translation Services:  does simple language translation of Word, PPT, and XLIFF files into HTML

Work Management Service:  provides task aggregation across systems such as SharePoint, Exchange and Project.

Azure Workflow Server is new and not exactly a service app but similar.  Provides an externalized host using REST and OAuth to run workflows.

Office Web Apps is no longer a service application

Web Analytics is no longer a service application

Office Web Apps

WAC is now a separate server product, not a service application

You can create a WAC farm that can support multiple SharePoint farms

You can view files from a number of different data sources, including:

SharePoint, Exchange, Lync, File servers

This allows you to scale and manage WAC separately from other Microsoft server products, as well as share that infrastructure between them

WAC farm version does not need to be in sync with SharePoint farm

You connect your SharePoint farm to the WAC farm using PowerShell

NewSPWOPIBinding

Analytics

New Replacement for Web Analytics Service

The Analytics Platform replaces the Web Analytics service application

Some of the reasons for that included:

There was no concept of item-to-item recommendations based on user behavior, i.e. people who viewed this also viewed foo

Couldn’t promote search results based on an item’s popularity (as determined by # of times an item was viewed)

It required a very powerful SQL box and significant storage and IO

Lists don’t have explicit view counts

The architecture had problems scaling to large numbers

How the New Platform Improves on Analytics

The new Analytics Processing engine aims to solve these issues:

Find relevant information (improve search relevance) – based on views, click thru, etc.

See what others are looking at (“hot” indicators and usage numbers – i.e. what’s popular based on # of views as well as # of unique users to view)

Understand how much content is being used (i.e. viewed) and how it compares to other documents

See discussion thread usage and find the hot topics

Use this popularity info to populate views through the Content by Search (CBS) WebPart

The model is extensible for 3^rd parties to build into the platform

Processing and Storing Analytics Data

Data goes through an analysis and reporting process that is contained within the search service application

Things like views and counts are combined with click-thru and other search metrics and pushed into the reporting database

Some data like view counts are also pushed into the index so it can be included in search results, sorted on (i.e. what’s most viewed), etc.

An analytics processing job examines data for clicks, links, tags, etc., as well as the usage data to create the data points used for reporting

Social Changes

Much more detail on social in the presentation on Social features, but worth highlighting:

User Profile Replication Engine

Profile Sync Changes

My Site Data Store Changes

Profile Sync Performance Improvements

Performance improvement goals are to reduce full import time from 2 weeks down to 60 hours for very large directories (i.e. 200K users, 600K groups)

Recent anecdotal evidence:  300K users, less than 7 hours for full import

Some of those improvements included:

Adding indexes to certain user properties that eliminated full table scans

Importing data from BDC in batches rather than one by one

Removing unused provisioning steps

Cleaning up unused historical data

Move resolution of some objects out of SharePoint and into the sync system

New Profile Synchronization Option

Active Directory Direct Import

Active Directory forest with multiple domains, one connection per domain

Selection of OUs from which to import

Import User and Group objects

Simple text-filters written in LDAP syntax

Full and incremental import

You can switch back between FIM and AD Direct

Changes in Social Data Store

The store for social data now is your personal site now – it’s no longer in the social DB

That means that social feeds will now come out of the content DB for My Sites

That gives you much more power to scale social features than SharePoint 2010

Single Social DB could become an I/O bottleneck in 2010

It also means that My Sites are required for
some social features, including feeds

SharePoint 2013 Farm Considerations

Stretched farms are no longer supported in SharePoint 2013

“Stretched” means different data centers with less than 1ms latency

All servers in the farm must be in the same data center now

For 100% fidelity in 100% of features, all content must reside the same farm

Certain social features will have a very slightly degraded experience unless content databases, personal sites and community sites are all together

Still allows for geo-grouped farms with full fidelity

Specific feature differences will be discussed in social deck

All above content has been picked up from the training material provided by the Microsoft. I will write more details blog about each of the topics. Meanwhile share your comments and wait for the next blog.

Enjoy SharePointing!!!