SPCA2013 - Best Practices & Considerations for Designing Your SharePoint Logical Architecture
Upcoming SlideShare
Loading in...5
×
 

SPCA2013 - Best Practices & Considerations for Designing Your SharePoint Logical Architecture

on

  • 608 views

Best Practices & Considerations for Designing Your SharePoint Logical Architecture

Best Practices & Considerations for Designing Your SharePoint Logical Architecture

Statistics

Views

Total Views
608
Views on SlideShare
608
Embed Views
0

Actions

Likes
1
Downloads
33
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

SPCA2013 - Best Practices & Considerations for Designing Your SharePoint Logical Architecture SPCA2013 - Best Practices & Considerations for Designing Your SharePoint Logical Architecture Presentation Transcript

  • Mirjam van Olst Best Practices & Considerations for Designing Your SharePoint Logical Architecture
  • About me http://sharepointchick.com @mirjamvanolst mirjam@outlook.com
  • Agenda Introduction Logical Architecture Design • Web Applications • Service Applications • Site Collections & Content Databases • Sites Wrap Up
  • Introduction
  • Logical Architecture Configuration of your SharePoint environment Continuous monitoring needed
  • Logical Architecture Design Get the most from out-of-thebox SharePoint Be able to scale your environment Avoid common health and performance challenges
  • Logical Architecture Design Functional Drivers • Shared security • Content rollup • Shared settings Technical Drivers • Boundaries
  • Logical Architecture Design Safest bet: use your crystal ball Second best: Good insight into the environment and the organization Thorough understanding of SharePoint internals
  • SharePoint Hierarchy Farm Servers Web Applications Content Databases Site Collections Sites Libraries and Lists Items
  • Logical Architecture Design
  • Logical Architecture Design 1 Web Applications 2 3 4 Service Applications Content Databases & Site Collections Sites
  • Web Application Considerations Potential Influences: – Intended Use – Scalability – SharePoint App policies – Host Header Web Applications vs. Host Named Site Collections
  • Host Named Site Collections Best practice for new deployments Created using PowerShell (no User Interface) Hosted in a single web application without a host header
  • Host header-less web applications SharePoint Apps Multi-Tenancy Request Management …expect more in the future New capabilities in SharePoint have been designed for, and expect a web application with no host header
  • When to use Path Based Sites Self Service Site Creation Unique wild card inclusion Managed Paths Security isolation with separate app pools
  • Host Named vs. Host Header Host Named Site Collections: Host Header Web applications: • • • 1 web application • Portal Team Sites / Project Sites My Sites
  • Custom Solutions Custom solutions can be deployed to: All Web Applications A specific Web Application The Farm
  • SharePoint Apps App Catalog per Web Application App settings for users per Web Application
  • SharePoint Apps
  • Software Boundaries Web Applications Limit Web Applications Zone Managed Path Application Pools Maximum Value 20 per farm 5 per web application 20 per web application 10 per web server Limit Type Supported Boundary Supported Supported
  • Reasons for multiple web apps Usage Service Applications SharePoint Apps and Custom Solutions
  • Logical Architecture Design 1 Web Applications 2 3 4 Service Applications Content Databases & Site Collections Sites
  • Service Application model Service Applications can easily be scaled out Web applications can pick and choose service applications Some Service Applications can be shared across farms
  • Service Applications
  • Proxy Groups • A proxy group is a group of Service Application Proxies (connections) that are selected for one or more web applications • By default, all Service Application Proxies are included in the default proxy group • A web application can: • Use the default proxy group • Use a custom proxy group and select service application proxies • A custom proxy group is specific to a web application when using the user interface
  • Proxy Groups User Profile Business Data Connectivity http://my App Management Machine Translation Excel Managed Metadata Excel Search Secure Store Visio Graphics http://teams http://projects http://intranet http://communities
  • Service Application Considerations Isolation Scalability What functionality and where?
  • Scaling of Services • First role to move to a dedicated server is crawl • Calculations in Excel Services could use a lot of CPU • User Profile synchronization single point of failure • Only one User Profile Service Application and one Search Service Application per server • Access Services needs it’s own SQL Server instance or SQL Server server
  • Logical Architecture Design 1 Web Applications 2 3 4 Service Applications Content Databases & Site Collections Sites
  • Content Databases • A content database should be within 100 to 200 GB • A site collection is always stored in a single content database • Limiting the size of a content database could be a reason to use multiple site collections
  • Sites and Site Collections Influencers People Content Site Types
  • Sites and Site Collections Within a site collection the following things can shared: • • • • • • • • • Navigation Content types Site Columns SharePoint Apps Master pages SharePoint Security groups Lookup fields for lists Search scopes Feature set
  • Sites and Site Collections Functional reasons for multiple site collections Complex security Separate backup and restore schedules and demands Site Collection quotas Decentralized administration
  • Sites and Site Collections Architectural reasons for multiple site collections More than 2000 sub sites per “site view” More than 250,000 sub sites More than 100-200GB of content Complex authorization structures per site
  • Software Boundaries Site Collections Limit Maximum Value Limit Type Site collections per farm 250,000 for non-personal site collections Supported Site collections per farm 750,000 Supported Site collections per content database 2,500 for non-personal site collections Supported Site collections per content database 5,000 Recommended Users in a site collection 2 million (after more than 1,000 the user interface will no longer scale and PowerShell should be used) Supported
  • Logical Architecture Design 1 Web Applications 2 3 4 Service Applications Content Databases & Site Collections Sites
  • Software Boundaries Security Limit Maximum Value Limit Type Security Scopes per list 5,000 Recommended Number of SharePoint groups a user can belong to 5,000 Supported Users in a SharePoint group 5,000 Supported Security principal per Access Control List (ACL) 5,000 Supported
  • Security Don’t use item level security if you can avoid it – “Sharing” an item or document means using item level security!
  • Security Don’t use item level security if you can avoid it – “Sharing” an item or document means using item level security!
  • Wrap up
  • Wrap Up Consider Functional and Technical drivers Thorough investigation and planning needed Design for growth Custom solutions add complexity and risk
  • THANK YOU