I'm in Redmond at Microsoft this week for SharePoint 2013 training. This course is 300-level technical training for Microsoft Partners to help us ramp up for the upcoming release. The focus is primarily on what has changed in SharePoint 2013 (there's an expectation we're familiar with SharePoint 2010 and SharePoint 2007).
The training is delivered by Steve Peschka, Mitch Prince, and Neil Hodgkinson.
It's Day One for me in the IT Pro track and I've taken a bunch of notes which I've summarized here. Enjoy!
Hardware/Software Requirements
On TechNet: Hardware and software requirements for SharePoint 2013 Preview
Hardware
Minimum hardware requirements are the same as SP2010, though there is now guidance for small and medium farms:
For WFE and application servers:
- Processor: 64-bit, 4-cores (small farm), 8 cores (medium farm)
- Memory: 8 GB for production (small), 16 GB (production, medium), 4 GB for development or evaluation. If you check out the TechNet article, linked to above, you'll see the memory requirements are insane. The values on that page aren't for RTM or reality.
- Storage: 80 GB
For database servers (or single-server farms), the minimum requirements are the same as SP2010:
- Processor: 64-bit, 4 cores (small), 8 cores (medium)
- Memory: 8 GB (small), 16 GB (medium)
Software
- All servers require Windows Server 2008 R2 SP1 x64 (Standard, Enterprise, Data Center, Web)
- SQL Server should be 64-bit SQL Server 2008 R2 SP1 x64. SharePoint 2013 supports SQL Server 2012 and there are some BI features that require SQL 2012 (I don't yet have any details)
Prerequisites
On TechNet: The preparation tool installs the following prerequisites
- Web Server (IIS) role
- Application Server role
- Microsoft .NET Framework version 4.5 Release Candidate (RC)
- SQL Server 2008 R2 SP1 Native Client
- Microsoft WCF Data Services 5.0
- Microsoft Information Protection and Control Client (MSIPC)
- Microsoft Sync Framework Runtime v1.0 SP1 (x64)
- Windows Management Framework 3.0 Release Candidate (RC) which includes Windows PowerShell 3.0
- Windows Identity Foundation (WIF) 1.0 and Microsoft Identity Extensions (previously named WIF 1.1)
- Windows Server AppFabric
- Cumulative Update Package 1 for Microsoft AppFabric 1.1 for Windows Server (KB 2671763)
Client Requirements
- For full Office integration, either Office 2010 or Office 2013 is required. Not sure what the full list of integration is.
- SharePoint Designer 2010 can still be used for 2010-mode sites, SPD2013 works for both 2010- and 2013-mode sites.
- SharePoint Workspace 2010 and SPW2013 work for both 2010- and 2013-mode sites.
Browser Requirements
On TechNet: Plan browser support in SharePoint 2013 Preview
Microsoft's goal is to support the latest in-market browsers (that is the most recent version of popular browsers).
Fully supported browsers
These are browsers that provide all SP2013 functionality to users. IE 9 (32-bit) and IE 8 (32-bit) are the only browsers in this list. ActiveX functionality is shipped with the Office client, so if the user has Office 2013/2010 installed they should have full functionality. I'm not clear on what functionality is available for Office 2007/2003 clients (if any).
Supported with limits
These browsers are supported but can't provide the full ActiveX functionality. IE9 (64-bit), IE8 (64-bit), Firefox (latest), Chrome (latest), Safari (latest). Office 2013 will ship with some ActiveX wrappers for Firefox to allow some ActiveX functionality that otherwise wouldn't be present (not sure which specific functionality).
Not Tested
IE7 (32-bit, 64-bit) has not been tested. Note, however, that the current 2013 browser support matrix on TechNet says IE7 is supported (32-bit fully, 64-bit limited), though Mitch said it hasn't been tested. It's safe to assume IE6 has not been tested either, so please do everyone a favour and upgrade. OK? Thank you.
Custom
For Web Content Management (WCM) sites (i.e., public-facing websites) you have the ability to control the HTML so you can define the level you will support. Please do not design for IE6 support. OK? Thank you.
Installation and Setup
This looks pretty much the same as it did with SP2010. The prerequisites installer still exists (though with different command line parameters to reflect the different prerequisites). Setup and the configuration wizard are the same.
Shredded Storage
The first big change Mitch presented was Shredded Storage. This is pretty cool (I can't find any info on TechNet, I really wish I could link to something). The goal of Shredded Storage is to make changes within the database equal to the size of the change, rather than to the size of the file. Essentially only the bits in a file that have changed (during an edit) are saved to the database. Lets take a look at how this works.
SharePoint 2010 uses the File Synchronization via SOAP of HTTP API (FSSHTTP, or "Cobalt") to transfer Office files between the WFE and the user. This API sends only the changes, however, once the user saves a document back to the SharePoint the WFE has to query SQL for the full file to compare and merge the change, then resaves the item back to SQL. When working with versions, each record in the table for a file's version contains a full copy of the version (e.g., generally a 1 MB file with 10 versions takes up 10 MB of disk). SharePoint 2013 uses Shredded Storage to reduce this duplication of data and save only the changes made during an edit to the database. This in effect means a file could consist of several records in a database, the sum of all records constituting the current version.
Mitch's presentation had a nice animation of the steps for both how it worked in SP2010 and how it will work in SP2013, which I will attempt to translate into an ordered list:
In SharePoint 2010:
- User requests document from WFE
- WFE requests document from SQL Server
- SQL reads full document
- SQL sends full document to WFE
- WFE sends full document to user
- User edits and updates document
- The updates are sent to the WFE (via Cobalt)
- WFE requests full document from SQL Server and reads it
- WFE merges updates
- WFE writes full document back to SQL
In SharePoint 2013, this process has changed:
- User requests document from WFE
- WFE requests document from SQL Server
- SQL reads full document
- SQL sends full document to WFE
- WFE sends full document to user
- User edits and updates document
- The updates are sent to the WFE (via Cobalt)
- (Changed) WFE saves updates to SQL as a new record (all parts of a document are somehow associated together)
Shredded storage is always turned on and is implemented for all files within SharePoint (other items too?). The interesting thing is that because the work is done by SharePoint, Shredded Storage works with RBS as well. My understanding is that you end up with many smaller files on your RBS media that constitute a single file. In the end, to use our 1 MB example with 10 versions, you end up using less than 10 MB of total storage (assuming there were no large edits) as each version would save only the changes.
Other SQL Improvements
Not a lot of details here, but some of the improvements are:
- Reduced scenarios that might involve full table scans (in other words, better SQL performance)
- Improvements around finding documents for link fix-up and alert handling
- Reduced data redundancy for some features (in other words, reduced data storage requirements)
- Advanced indexing features provided by SQL 2008 R2 (recall SP2010 was released before SQL 2008 R2 so any improvements have taken time to implement)
- Changes in architecture to support wide lists (single item spans multiple rows in the database)
Distributed Cache Service
The Cache Service is new to SharePoint 2013. It uses the Windows Server AppFabric distributed cache technology ("Velocity") to help speed up features like authentication (by caching tokens) and My Site social feeds (by caching said information). Windows Azure Cache cannot be used for this as it currently only supports local caching. Apparently the version that ships with SharePoint is the only version that will be supported (I guess they haven't finalized this yet).
In the pre-release version, the caching service is automatically provisioned and started on all servers in the farm. This will change with RTM as there are specific recommendations. This service will try to eat as much RAM as it can, however its performance doesn't improve when the memory of the server is greater than 16 GB. Of the 16 GB, you should allocate 2 GB to the OS, and 50% of the remaining memory (14 GB * 50% = 7 GB) to overhead and the remaining 7 GB to the actual cache storage. When you go above 7 GB, there is a significant performance hit when the cache needs to flush. It is recommended that the service not be run on WFEs (where you would think caching would make sense) not on an application server that is running any other services. In other words, cache servers should be dedicated. Oh boy, more servers in the farm! This recommendation comes directly from the cache team. This service uses the farm account for startup (no managed accounts it seems) much like the UPS. In other words when provisioning this service the farm account needs to be a local administrator which as we all know is not a best practice.
Data stored in the cache is distributed across all cache servers, however, it is not duplicated so there is no HA. If an item isn't in the cache it's retrieved from SQL and cached. If a cache server drops offline, any requests for its cache will fail and the WFE will have to query SQL. There would therefore be a performance hit when a cache server goes down until the other cache servers are populated with the lost data. If you're going to intentionally take a cache server offline, run the Stop-SPDistributedCacheServiceInstanceGracefullyOnLocalServer cmdlet (yeah, that's a real cmdlet name) to copy the server's cache to the other cache servers. The cache for an item automatically expires after 1-2 weeks.
There will be health analysis rules and cache server performance counters added to a server so you can monitor its performance. These counters include # reads, # writes, # hits, # misses, time for read, time for write, total I/O.
As of now, there is no guidance on scaling out neither the cache nor any recommendations on capacity and performance because they're still testing. Eventually there will be some overall cache sizing guidance to help determine how many cache servers you'll need. It will be something like total storage / 7 GB = # of cache servers needed. Note that not all content is cached so for farms with terabytes of data this doesn't mean you'll need hundreds of cache servers.
Request Management
Another big topic that prompted lots of questions was the new Request Management (RM) feature that gives SharePoint more knowledge of the state of the farm and control over where to direct incoming requests. The feature is off by default and can be turned on and configured using PowerShell (there's an entire lab dedicated to this so I'll likely have more info once I work through this later this week).
Looking at my notes for the morning, this topic had the most discussion and information (there were tons of questions). Basically the way RM works is when a user makes a request to a WFE, SharePoint will determine which WFE in the farm is best suited to handle the request using a system of rules and server scores. This processing obviously provides some overhead—their goal is to incur an impact of no more than 10 milliseconds per request. 10 ms is a lot of time in the context of large public websites, and I can't see this being tolerated even though a large farm would benefit from this feature.
Mitch and Steve provided the "common scenarios" where you would use RM. These use cases didn't seem common to me, they came across as Microsoft's intended uses for RM (though I'm sure customers must be asking for this functionality otherwise it wouldn't have been developed): target crawls at a specific WFE (using hosts files is so MOSS 2007), isolating traffic for troubleshooting (now you no longer need to guess which WFE is serving your request, though this would obsolete Todd Klindt's advice of using host files), reallocating the overall load to the WFEs (e.g., add in a new WFE that is twice as powerful as existing WFEs, allocate more traffic to the new hardware and less to the old). As we got into it a bit, it was clear this is a technology for farms with several WFE servers and provides a more application-aware context than hardware load balancers can provide (though they pointed out you shouldn't be tossing out your load balancers for RM).
Basically RM sounds to me like an intelligent load balancer. It doesn't replace the need for an actual load balancer, but it can route using a more complex set of criteria.
To route requests, RM uses Routing Rules, ExecutionGroups (does not involve a mob of people, rather it is a group of routing rules; May I suggest a new name?) and MachinePools—logical groups of WFEs (a WFE can be in multiple MachinePools).
A routing rule allows you to filter the request based on some properties of the request. You can combine one or more rules into an ExecutionGroup and there are three ExecutionGroups (0, 1, and 2) which are iterated through until a match is made. When the request comes in, SharePoint will check all of the rules in ExecutionGroup 0. If any one of the rules in the ExecutionGroup returns a match it will send the request into an associated MachineGroup. If there is no match, SharePoint will proceed to ExecutionGroup 1. It does the same thing here and if there is still no match ExecutionGroup 2 is used. If there are no matches after checking ExecutionGroup 2, the WFE will select any available routing target.
Once a MachineGroup is selected, SharePoint evaluates which WFE to forward the request to using two weighting criteria: Static weights and Health weights. Static weights are manually provided by an administrator. The default weight is 1. A lower number carries more weight (I personally feel this is backwards). The Health weight is entirely dynamic and calculated by SharePoint. By default the health weight is 4. The health weight can range from 0 (healthy) to 10 (unhealthy? sick? SharePoint tuberculosis). Again, to me this seems backwards though it does follow the same pattern for network card metrics (http://support.microsoft.com/kb/258487) so there is precedent.
Clever trick: If you want to route to a subset of machines you can create a rule that has no criteria and then specify the subset of machines. I suppose if there is no criteria it automatically matches (null == true?).
Wow, there's a lot there, but we're not done (confused yet?)! In addition to routing rules (RR), you can create Throttling Rules (TR). SP2010 had throttling, but it wasn't so good. In SP2010 all WFEs attached their health information to their responses and it was up to the client to do anything with this information. If a WFE failed or was busy a client would receive an error or message instead of being redirected to another available WFE. So now with RM you can set up Throttling Rules (TR), which are rules to deny access to WFEs. That is, RRs process requests and TRs stop requests.
The TRs match on the properties Url, UrlReferrer, UserAgent, Host, IP, HttpMethod, SoapAction, CustomHeader (this property can be leveraged to make applications routing-aware!) and can be evaluated with StartsWith, EndsWith, Equals, or a regular expression.
Example: Say you have an application like OneNote that is generating lots of requests. While this seems odd, when you check your calendar you see that today is actually National Note Taking Day and you realize all of your colleagues are furiously documenting the minutia of their day. And I guess none of them are bloggers. Anyway, there all of these OneNote clients are making so many requests to SharePoint that it is affecting the other users of the site who didn't get the memo about taking notes and are just trying to browse the pictures from office Christmas party. One of these employees is of course the CIO and viewing these pictures is of the utmost importance thereby assigning you the task of sorting this out. In comes throttling rules. We all know that OneNote identifies itself when connecting to a web server by putting the text "OneNote" within its user agent string (duh). You can create a TR that matches the user agent with a regex for "OneNote" and deny them from accessing a particular WFE. All their requests will go to another WFE and the laz... socially in touch employees and wonderful CIO will be free to continue browsing blurry cell phone pictures of the accounting department. It's not clear to me why you would choose a TR over a RR since they essentially achieve the same result (I suspect it is because the TR filters on these properties while the RR does not).
In any event, Spence Harbar already has a three part guide on Request Management (two parts are published as of this post) that is well worth reading.
New Service Applications
There are some new service applications in SharePoint 2013! Let's take a quick look:
App Management Service — allows the installation of SharePoint Apps from the Office Marketplace or the App Catalog
SharePoint Translation Services — simple language translation of Word, PowerPoint and XLIFF files into HTML. I think for more organizations that require translated documents you'll still have humans doing this work.
Work Management Service — aggregates the many Task Lists that are littered through a farm. It will also aggregate tasks from Exchange and Project Server, which is really cool, and it does all of this into a single place (within your My Site I'm assuming) so you can see all tasks assigned to you. Personally I've found task list adoption to be low (the fact that there are many lists didn't help). I see this as something that will help out with adoption.
Azure Workflow Service — not a service application, but it's new! This allows an external host to run workflows. The default example is Azure, though another third party hosted service can be used.
Office Web Apps
Office Web Apps is no longer the tightly attached parasitic service application that it was in SharePoint 2010, now it's an entirely separate product and SKU! Possibly multiple SKUs! While the finance department will be shaking their heads about this one, this is actually an awesome architecture move as it allows OWA to be consumed by multiple farms, Exchange, Lync, and file servers. This is so cool. The functionality has been increased as well: now you can comment, create documents directly in OWA, multi-user authoring now includes PowerPoint and Word, and there's support for asynchronous navigation and media playback. Asynchronous navigation lets a presenter provide a PowerPoint deck to others, and they can browse through the slide independently of what the presenter is showing. This is useful if you want to check something the presenter said a couple of slides back. Media playback is AWESOME. In SharePoint 2010, with FAST you could see thumbnails of a document or slideshow in Search results. This functionality is now part of OWA and has been expanded to let you see a slideshow or other media when you hover over a link to a document within SharePoint.
I was watching the demos and playing around with OWA in the lab today and all I could think was that this is probably the last version of Office that will be released as a desktop application.
Here's an interesting bit about upgrading OWA. Major to Major in place upgrades are not supported (O15 to O16 for example). Instead a new farm must be built. But that's OK. Service Packs and CUs can be applied however the server cannot be part of an OWA farm when you do this. The trick is to remove a server from the farm, patch it, and repeat with a few more OWA servers (did I mention you'll have multiple OWA servers?) After you have a few that are updated, point SharePoint at the updated OWA farm and then upgrade the rest (removing them, upgrading, joining) until done. This is the same procedure for a single OWA server as well. Yes, you need to remove the one server from the "farm", update it, and then create a new farm. You'll experience an outage to OWA while this happens.
Analytics
Web analytics is no longer its own service application and has been rolled into the search service. This is neat and it now provides a way to provide more relevant search results. We didn't get into too much detail with this analytics.
Social Changes
The User Profile Replication Engine (UPRE) that was part of the SharePoint Administration toolkit has been brought into the SharePoint team, ensuring it receives improved development and testing. How this tool will be provided (part of the media, separate download, part of another toolkit) is still unknown.
Profile Synch
Spence Harbar covers this excellently in his post, First Look: SharePoint Server 2013 Active Directory Import. Biggest change is the new Active Directory Direct Import method that can be used to cure you of the woes caused by FIM. FIM has also been updated significantly to make it much better. Mitch told a story about a customer with 200,000 users and 600,000 groups whose import took two weeks in SharePoint 2010. In 2013, the import took a mere five days.
Social Data store
All social data now lives in your personal site and is no longer in the social database. This means you now require My Sites for social feature. This will probably make backup and restore of the UPA easier. The primary reason for this change was the social DB was the I/O bottleneck in farms with lots of social activity. Social data is included in the site collection quota calculations. Beware!
You can no longer consume a UPA over a WAN, it's recommended for best functionality that there is a single UPA in the farm, otherwise there will be slight degradation of functionality (users may not see all social activity in their news feeds).
Other Tidbits
Reliance on Alternative Access Mappings (AAM) is being reduced, the preference is to create host-header site collections in a single web application, the model used by Office 365. AAMs aren't going away, you should still use them for the following scenarios:
- When you need out of the box self-service site creation
- When unique wild card inclusions are required within a web application (wild card inclusion shared across all host-name sites which may not be desirable to you)
- You want the additional security provided by multiple web apps with separate application pools (Board of Director sites are notorious for this)
Self-Service Site Creation (SSSC) has been updated. The link to create site collections is now in a user's My Site (which means My Sites are required for SSSC!). There is a new page used for SSSC in SP2010—selfservicecreate.aspx. Sending requests to scsignup.aspx will result in a situation similar to Progress Quest. By default SSSC will create team sites, if you want other templates you'll need to create a custom request form (I don't have any details how).
Themes are pretty neat and easy to apply/change. They're XML-based and support HTML5. You can no longer use PowerPoint for creating these (seriously). Reminds me a lot of WordPress themes.
Sharing's been improved. It's easy now to see who has access to a resource, along with all access requests. You can request access on someone else's behalf, and you can have a dialog with a user to determine the appropriate rights needed. This fixes a long-standing administrative quirk of SharePoint's. I'm very happy to see this. Before I forget, this functionality requires the outgoing email settings to be configured otherwise only site administrators have the functionality. There was something else... something really amazing... Oh right! You can now grant rights to distribution groups! I can't remember the last time I worked with a client who didn't ask for this. It has finally arrived! If you have lots of distribution lists, I recommend upgrading all your SharePoint farms just for this (I'm serious).
The two biggest changes and investments in this version of SharePoint are in search and social (this was repeated several times). When I looked at the new features it reminded me of Google and Facebook.
Finally, one last thing: With much rejoicing, stretched farms are no longer supported in SP2013. In SP2010 you could have servers that were part of the same farm in different geographic locations as long as you could stay within the 1ms latency. Now we just need to come up with a good geographically distributed architecture!
