Mirjam van Olst

Best Practices & Considerations for Designing

Your SharePoint Logical Architecture

About me

http://sharepointchick.com

@mirjamvanolst

mirjam@outlook.com

Introduction Logical Architecture

Design

• Web Applications

• Service Applications

• Site Collections &

Content Databases

• Sites

Agenda

Wrap Up

Introduction

Configuration of

your SharePoint

environment

Logical Architecture

Continuous

monitoring

needed

Get the most

from out-of-the-

box SharePoint

Logical Architecture Design

Be able to

scale your

environment

Avoid common

health and

performance

challenges

Functional Drivers

• Shared security

• Content rollup

• Shared settings

Logical Architecture Design

Technical Drivers

• Boundaries

Second best:

Good insight into

the environment

and the

organization

Logical Architecture Design

Thorough

understanding of

SharePoint

internals

Safest bet: use your crystal ball

Items

Libraries and Lists

Sites

Site Collections

Content Databases

Web Applications

Servers

Farm

SharePoint Hierarchy

Logical Architecture Design

Logical Architecture Design

1 2 3 4Web

ApplicationsService

ApplicationsSitesContent

Databases & Site

Collections

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

SharePoint

Apps

Multi-Tenancy Request Management

…expect more in the future

Host header-less web applications

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:• 1 web application

Host Header Web applications:• 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 BoundariesWeb Applications

Limit Maximum Value Limit Type

Web Applications 20 per farm Supported

Zone 5 per web application Boundary

Managed Path 20 per web application Supported

Application Pools 10 per web server Supported

Reasons for multiple web apps

Usage Service

Applications

SharePoint

Apps and

Custom

Solutions

2

Logical Architecture Design

1 3 4Web

ApplicationsService

ApplicationsSitesContent

Databases & Site

Collections

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

http://intranet

http://my

http://communities

http://teams

http://projects

Business Data

Connectivity Managed

Metadata

User ProfileExcel

Search

App

Management

Visio Graphics

Excel

Machine

Translation

Secure Store

Proxy Groups

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

2

Logical Architecture Design

1 3 4Web

ApplicationsService

ApplicationsContent

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 CollectionsInfluencers

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

Complex

security

Separate

backup and

restore

schedules and

demands

Site Collection

quotas

Decentralized

administration

Sites and Site CollectionsFunctional 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

Sites and Site CollectionsArchitectural reasons for multiple site collections

Software BoundariesSite 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

2

Logical Architecture Design

1 3 4Web

ApplicationsService

ApplicationsSitesContent

Databases & Site

Collections

Software BoundariesSecurity

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

Consider

Functional

and

Technical

drivers

Thorough

investigation

and planning

needed

Design for

growth

Custom

solutions add

complexity

and risk

Wrap Up

THANK YOU