On any SharePoint project, the core of the solution being built should be designed and architected first before being developed. With the flexibility of SharePoint solutions (specifically SharePoint 2013), there is never one way to design it right. The experienced SharePoint Architect however is able to figure out the best way for the project, constraints and client at hand. This session is meant to give insight to the average SharePoint Professional on what it takes to become and be a SharePoint Architect. It will help guide the aspiring SharePoint Architect on the items that really need to be thought of when designing a SharePoint solution for your client and at the same time divulge some tricks of the trade learned from the countless enterprise SharePoint solutions I have successfully implemented over the years.
14. Hardware Requirements (Web servers)
Memory Processor Disk
Single Server Foundation
(Integrated or
Standalone Database)
8 GB x64 1x4 cores 80 GB (OS)
Single Server
(Integrated or
Standalone Database)
*Development
Environment/Evaluation
10 GB*
24 GB
*Min services for Dev
x64 1x4 cores 80 GB (OS)
Web / Application
Servers
*Pilot, Production,
Servers in a Farm
12 GB x64 1x4 cores 80 GB (OS)
Want a full list? Go to my blog post: http://www.khamis.net/Blog/Post/267/SharePoint-2013---Hardware-and-Software-Requirements-and-Prerequisites
15. Hardware Requirements (DB servers)
Memory Processor Disk
Small Deployments
(< 1,000 users) 8 GB x64 1x4 cores 80 GB (OS)
Medium Deployments
(< 10,000 users) 16 GB x64 1x8 cores 80 GB (OS)
Large Deployments
(> 10,000 users) Depends on Size Depends on Size 80 GB (OS)
Want a full list? Go to my blog post: http://www.khamis.net/Blog/Post/267/SharePoint-2013---Hardware-and-Software-Requirements-and-Prerequisites
17. Deployment Requirements
SharePoint 2013 SharePoint 2010
Workgroup Unsupported Supported
Domain Controller
Only for Developer
Installation
Supported for SBS
Client OS Unsupported Developer Installation
Dynamic Memory in VMs Unsupported Unsupported
Windows Web Server Unsupported Supported
Source: SPC 2012
18. Browser Support
Client Computer Browser Support SP 2010 SP 2013
Internet Explorer 10/11 32-bit Supported Supported
Internet Explorer 10/11 64-bit Supported with Limitations Supported with Limitations
Internet Explorer 9 32-bit Supported Supported
Internet Explorer 9 64-bit Supported with Limitations Supported with Limitations
Internet Explorer 8 32-bit Supported Supported
Internet Explorer 8 64-bit Supported with Limitations Supported with Limitations
Internet Explorer 7 32-bit Supported Not supported
Internet Explorer 7 64-bit Supported with Limitations Not supported
Internet Explorer 6 Not supported Not supported
Google Chrome (latest released version) Supported with Limitations Supported with Limitations
Mozilla Firefox (latest released version) Supported with Limitations Supported with Limitations
Apple Safari (latest released version) Supported with Limitations Supported with Limitations
Want a full list? Go to my blog post: http://www.khamis.net/Blog/Post/268/SharePoint-2013-Browser-Support-Matrix
24. At the top of mind for any SharePoint Architect
Why? Flexibility, Boundaries & Limitations
25. Boundaries and Limitations
More Info:
http://www.khamis.net/Blog/Post/260/S
harePoint-2010-vs--SharePoint-2013-
Boundaries-and-Limits-Comparison
Limit Name SharePoint 2010 Maximum
Value
SharePoint 2013 Maximum
Value
Web application limits
Web application Not Published 20 per farm
Content database 300 per Web application 500 per Web application
Zone 5 per Web application 5 per Web application
Managed path 20 per Web application 20 per Web application
Solution cache size 300 MB per Web application 300 MB per Web application
Site collection (sites and sub-sites) 250,000 per Web application 250,000 per Web application
Web server and application server limits
Application pools 10 per Web server 10 per Web server
Content database limits
Number of content databases 300 per Web application 500 per farm
Content database size (general usage
scenarios)
200 GB per content database 200 GB per content database
Content database size (all usage
scenarios)
4 TB per content database 4 TB per content database
Content database size (document
archive scenario)
No explicit content database
limit
No explicit content database
limit
Content database items 60 million items including
documents and list items
60 million items including
documents and list items
Site collections per content database 2,000 recommended
5,000 maximum
5,000 recommended
10,000 maximum
32. App Model vs Traditional – Choose wisely
Farm Solutions
• Full trust solutions
• Access to file systems
• Classic model from 2007
• Deploy to the GAC
• Access to the 14 Hive
• DLL’s and .NET Managed Code
Sandbox Solutions
• Declarative elements
• Partially trusted code with limited
API support
• DLL’s and .NET Managed Code
• No access to server
Apps
• New Apps model
• Deployed from corporate catalog or
office market place
• Manage permission and licenses
specifically
• Preferred option
• No server code!
---------------- Solutions Model -------------------- ------ App Model ------
Provider
Hosted
Auto
Hosted
SharePoint
Hosted
X
34. Extensive CSOM and REST API Coverage
And more..BCS
AnalyticsWorkflow
eDiscoveryPublishing
TaxonomySocial
Sharing
Search
35. External Access for Extranet and Internet Sites
http://channel9.msdn.com/Events/SharePoint-Conference/2014/SPC333
Want more information? http://technet.microsoft.com/en-us/library/cc263513(v=office.14).aspx
49. Folders vs Metadata
Advantages of folders Disadvantages of folders
Segregation Harder to find specific items/more clicks
Permissions URL length increased
Default metadata Hard to navigate through folder levels
Easily transitioning from file shares Folder metadata lacking
Scaling Can lose a document in wrong folder
Windows Explorer friendly No breadcrumb
Play nice with document sets Tricky to iterate through
Easier to migrate Filtering and sorting drawbacks
Provides support for Windows PowerShell 3.0
.NET Framework 4.5
Provides in memory distributed caching
Provides support for information protection
Enables the creation & consumption of OData services
Minimal Download Strategy
Downloads delta between page requests
Implements a download manager interfacing between controls/content placeholders on page and server to determine what content requires update
Request Management
Prioritizes and routes incoming requests
Route requests to Web servers that have good health characteristics
Identify and block known bad requests
Prioritize requests by throttling lower-priority requests (such as services that run in the background) and serving higher priority requests (such as end user requests)
Route requests of specific types (such as search) to specific servers in the farm
Cache Service
New distributed cache service based on Windows Server AppFabric Distributed Caching
Shredded Storage
Files shredded and stored in SQL Server
Updated bits are mapped to shredded BLOBs
Mitigates request and update roundtrips to WFE(s)
Deferred Site Collection Upgrades
Separation of schema and site collection upgrade
Schema is upgraded to SharePoint 2013 and run with SharePoint 2010 features and visuals
Enables existing SharePoint 2010 site collections to work unchanged in SharePoint 2013
Site Collection Health Checks
Exposed to Site Collection Administrators (cmdlets for Farm Administrators)
Identifies common known issues
Missing Features and Templates
Helps address post-upgrade issues:I.e. (Un-ghosted files)
Evaluation Site Collections
Allows Site Collection Administrators to preview SharePoint 2013 w/o upgrading production Site Collection
Enabled through a copy of production Site Collection
Analytics based on Search
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
Large collections of Records require careful planning on numbers and locations of content databases, site collections, sites and document libraries in relation to the file plan
SharePoint now supports multiple index servers
Content index can now be divided into multiple index partitions.
Each index server can be configured to run multiple crawlers. Multiple crawlers can crawl content in parallel
Index servers are now stateless. The crawlers build the content index and propagate directly to the query servers.
multiple query servers benefits of redundancy and parallel performance can be made available
crawl management and property store data tables have been split into separate databases and multiple tables of this kind can be configured.
Remote Blob Storage:
As of SP2007 SP1, it was possible to take advantage of an External BLOB Storage (EBS) API to get the BLOBs out of SQL Server.
The method was not transactionally consistent and it results in a high number of orphaned BLOBs in the BLOB store because new BLOBs are stored (not replaced) when a document is updated.
New Remote Blob Storage features of SharePoint 2010 provide:
1. Transactional consistency: this ensures that when we get a BLOB ID back from the RBS provider, we are guaranteed storage. It also allows for traditional update capabilities.
2. Transactional consistency also allows Write Once Read Many (WORM) mode devices to "VETO" a delete or modify operation. If external vendors such as EMC choose to write an RBS provider for their devices, then the actual storage subsystem itself can prevent SharePoint from allowing a document to be deleted.
3. While orphan cleanup is much less of a concern with RBS it still needs to be managed. The good news is that because RBS is managed through SQL tables, RBS can take advantage of indexes to actually "query" the difference between what is in the BLOB store and what is in SharePoint content databases.
4. RBS is completely transparent to the SharePoint API. Nothing changes. So existing custom and 3rd Party code will continue to function as expected.
With binary data out of the content database, only metadata may be present causing a great reduction to the database size and improving scalability and performance.
App
Deployment and migration issues
Scale
Cost
Storage
Integration
Loss of control
Existing SharePoint architecture
2-3 year release cadence, Office 365 gets all the goodies first
http://technet.microsoft.com/en-us/library/ff621103(v=office.15).aspx
Bust the “I like to have SQL on a physical server” excuse
non-uniform memory access
for instances of SQL Server that host SharePoint databases to make sure that a single SQL Server process serves each request.
http://technet.microsoft.com/en-us/library/hh292622(v=office.15).aspx
disk-based cache that stores files , load quickly in the browser, and reduces the load on the database server when it uses those files. These files are known as binary large objects blobs
querying for items is linked with the user account that makes the query. Various parts of the publishing feature make queries for which the results are cached in the object cache
http://technet.microsoft.com/en-us/library/cc261797(v=office.15).aspx
http://technet.microsoft.com/en-us/library/jj219572.aspx caching