Sunday, September 30, 2012

SharePoint 2013 Changes and Enhancements from SharePoint 2010

First thing I would like to say that SharePoint 2013 Rocks!!!  Last week [24th 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

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 3rd 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!!!