There are a myriad number of approaches to design and architecture of SharePoint servers, not all of which are ideal. Since the design of a SharePoint environment is subsequently critical to its performance and functionality, it is important to understand what are the best practices around SharePoint infrastructure design. SharePoint architects need to be aware of the various installation options, the differences between SharePoint search architecture models, how and when to virtualise SharePoint, and ways to optimise the SQL Database tier of SharePoint. This session goes right to the heart of the matter, providing for physical and virtual architecture guidelines and specific configuration settings that can immediately be used to construct best practice SharePoint 2013 and 2010 environments. In addition, a high-level look at architecture changes in SharePoint 2013 and new models at the data tier in SQL 2012 are outlined. Real-world advice obtained from the presenter’s experience designing hundreds of production SharePoint farms is provided, and the installation options are discussed frankly.

1. Michael Noel, CCO

2. Thank you to our sponsors

3. Great to be back in Beautiful Australia!

5. • Windows Server 2008 R2 SP1 or
Windows Server 2012 (Preferred)
• SQL Server 2008 R2 w/SP1 or SQL Server
2012 (Preferred)
Type Memory Processor
Dev/Stage/Test server 8GB RAM 4 CPU
‘All-in-one’ DB/Web/SA 24GB RAM 4 CPU
Web/SA Server 12GB RAM 4 CPU
DB Server (medium environments) 16GB RAM 8 CPU
DB Server (small environments) 8GB RAM 4 CPU
Software/Hardware Requirements

6. • Office Web Apps is no longer a service application
• Web Analytics is no longer service application, it’s part of
search
• New service applications available and improvements on
existing ones
• App Management Service – Used to manage the new SharePoint
app store from the Office Marketplace or the Application Catalog
• SharePoint Translation Services – provides for language
translation of Word, XLIFF, and PPT files to HTML
• Work Management Service – manages tasks across SharePoint,
MS Exchange and Project.
• Access Services App (2013) – Replaces 2010 version of Access
Services
Changes in Service Applications and New Service Applications

7. • A new Windows service – the Distributed
Cache Service – is installed on each server in
the farm when SharePoint is installed
• It is managed via the Services on Server page
in central admin as the Distributed Cache
service
• The config DB keeps track of
which machines in the farm
are running the cache service
Distributed Cache Service

8. • 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
Request Management (RM)

9. • Option 1 (AD Import): Simple one-way
Sync (a la SharePoint 2007)
• Option 2: Two-way, possible write-back
to AD options using small FIM service
on UPA server (a la 2010)
• Option 3: Full Forefront Identity
Manager (FIM) Synchronisation, allows
for complex scenarios – Larger clients
will appreciate this
User Profile Sync – Three Options for Deployment

10. • SharePoint 2013 continues to offer support for
both claims and classic authentication modes
• However claims authentication is THE default
authentication option now
• Classic authentication mode is still there, but can
only be managed in PowerShell – it’s gone from the
UI
• Support for classic mode is deprecated and will go
away in a future release
• There also a new process to migrate accounts
from Windows classic to Windows claims – the
Convert-SPWebApplication cmdlet
Claims-based Authentication - Default

11. • Stores new versions of documents as ‘shredded
BLOBs that are deltas of the changes
• Promises to reduce storage size significantly
Shredded Storage

12. • New Search
architecture
(FAST based)
with one
unified search
• Personalised
search results
based on
search history
• Rich contextual
previews
Search – FAST Search now included

14. Web
Service Apps
Data
Three Layers of SharePoint Infrastructure

15. • ‘All-in-One’ (Avoid)
 DB and SP Roles Separate
Small Farm Models

16. • 2 SharePoint Servers running
Web and Service Apps
• 2 Database Servers
(AlwaysOn FCI or AlwaysOn
Availability Groups)
• 1 or 2 Index Partitions with
equivalent query components
• Smallest farm size that is fully
highly available
Smallest Highly Available Farm

17. • 2 Dedicated Web
Servers (NLB)
• 2 Service Application
Servers
• 2 Database Servers
(Clustered or
Mirrored)
• 1 or 2 Index Partitions
with equivalent query
components
Best Practice ‘Six Server Farm’

18. • Separate farm for
Service Applications
• One or more farms
dedicated to content
• Service Apps are
consumed cross-
farm
• Isolates ‘cranky’
service apps like
User Profile Sync and
allows for patching
in isolation
Ideal – Separate Service App Farm + Content Farm(s)

19. • Multiple Dedicated
Web Servers
• Multiple Dedicated
Service App Servers
• Multiple Dedicated
Query Servers
• Multiple Dedicated
Crawl Servers, with
multiple Crawl DBs to
increase parallelisation
of the crawl process
• Multiple distributed
Index partitions (max
of 10 million items per
index partition)
• Two query components
for each Index
partition, spread
among servers
Large SharePoint Farms

21.  Allows organisations that wouldn’t normally be able to have a test
environment to run one
 Allows for separation of the database role onto a dedicated server
 Can be more easily scaled out in the future
Sample 1: Single Server Environment

22.  High-
Availability
across Hosts
 All
components
Virtualised
Sample 2: Two Server Highly Available Farm

23.  Highest
transaction
servers are
physical
 Multiple farm
support, with
DBs for all
farms on the
SQL AOAG
Sample 3: Mix of Physical and Virtual Servers

24. Scaling to Large Virtual Environments

25. • Processor (Host Only)
• <60% Utilisation = Good
• 60%-90% = Caution
• >90% = Trouble
• Available Memory
• 50% and above = Good
• 10%-50% = OK
• <10% = Trouble
• Disk – Avg. Disk sec/Read or
Avg. Disk sec/Write
• Up to 15ms = fine
• 15ms-25ms = Caution
• >25ms = Trouble
• Network Bandwidth –
Bytes Total/sec
– <40% Utilisation = Good
– 41%-64% = Caution
– >65% = Trouble
• Network Latency - Output
Queue Length
– 0 = Good
– 1-2= OK
– >2 = Trouble
Virtualisation of SharePoint Servers
Virtualisation Performance Monitoring

27. Sample Distributed Content Database Design

28. • Can reduce dramatically the size of Content DBs, as upwards
of 80%-90% of space in content DBs is composed of BLOBs
• Can move BLOB storage to more efficient/cheaper storage
• Improve performance and scalability of your SharePoint
deployment – But highly recommended to use third party
Remote BLOB Storage (RBS)

30. DB-A
File 1
DB-B
File 1
Volume #1
DB-A
File 2
DB-B
File 2
Volume #2
DB-A
File 3
DB-B
File 3
Volume #3
DB-A
File 4
DB-B
File 4
Volume #4
Tempdb File 1 Tempdb File 2 Tempdb File 3 Tempdb File 4
Multiple Files for SharePoint Databases

31. • Break Content Databases and TempDB into multiple files (MDF, NDF), total
should equal number of physical processors (not cores) on SQL server.
• Pre-size Content DBs and TempDB to avoid fragmentation
• Separate files onto different drive spindles for best IO perf.
• Example: 50GB total Content DB on Two-way SQL Server would have two
database files distributed across two sets of drive spindles = 25GB pre-sized
for each file.
Multiple Files for SharePoint Databases

32. • Implement SQL Maintenance Plans!
• Include DBCC (Check Consistency) and either Reorganize
Indexes or Rebuild Indexes, but not both!
SQL Database Optimisation
SQL Maintenance Plans
• Add backups into the
maintenance plan if they
don’t exist already
• Be sure to truncate
transaction logs with a T-
SQL Script (after full
backups have run…)

34. High Availability and Disaster Recovery
SQL Server Solution
Potential
Data Loss
(RPO)
Potential
Recovery Time
(RTO)
Automatic
Failover
Additional
Readable Copies
AlwaysOn Availability Groups – Synchronous (Dual-phase
commit, no data loss, can’t operate across WAN)
None 5-7 Seconds Yes 0 - 2
AlwaysOn Availability Groups – Asynchronous (Latency
tolerant, cross WAN option, potential for data loss)
Seconds Minutes No 0 - 4
AlwaysOn Failover Cluster Instance (FCI) – Traditional
shared storage clustering
NA 30 Seconds to
several minutes
(depending on
disk failover)
Yes N/A
Database Mirroring - High-safety (Synchronous) Zero 5-10 seconds Yes N/A
Database Mirroring - High-performance (Asynchronous) Seconds Manually
initiated, can be
a few minutes if
automated
No N/A
SQL Log Shipping Minutes Manually
initated, can be
a few minutes if
automated, by
typically hours
No Not during
a restore
Traditional Backup and Restore Hours to
Days
Typically
multiple hours,
days, or weeks
No Not during
a restore
Comparison of High Availability and
Disaster Recovery Options

35. AlwaysOn Availability Groups in SQL 2012

36. Creating SQL 2012 AOAGs

37. • Hardware Based Load Balancing (F5,
Cisco, Citrix NetScaler – Best
performance and scalability
• Software Windows Network Load
Balancing fully supported by MS, but
requires Layer 2 VLAN (all packets must
reach all hosts.) Layer 3 Switches must
be configured to allow Layer 2 to the
specific VLAN.
• If using Unicast, use two NICs on the
server, one for communications
between nodes.
• If using Multicast, be sure to configure
routers appropriately
• Set Affinity to Single (Sticky Sessions)
• If using VMware, note fix to NLB RARP
issue (http://tinyurl.com/vmwarenlbfix)
Network Load Balancing

39. • Infrastructure Security and Best practices
• Physical Security
• Best Practice Service Account Setup
• Kerberos Authentication
• Data Security
• Role Based Access Control (RBAC)
• Transparent Data Encryption (TDE) of SQL Databases
• Transport Security
• Secure Sockets Layer (SSL) from Server to Client
• IPSec from Server to Server
• Edge Security
• Inbound Internet Security (Forefront UAG/TMG)
• Rights Management
Five Layers of SharePoint Security

40. • Document all key settings in IIS, SharePoint, after
installation
• Consider monitoring for changes after installation
for Config Mgmt.
• Fantastic tool for this is the SPDocKit - can be found
at http://tinyurl.com/spdockit
SPDocKit

41. Michael Noel
Company Site: http://www.cco.com
Twitter: http://twitter.com/michaeltnoel
LinkedIn: http://linkedin.com/in/michaeltnoel
Facebook: http://facebook.com/michaelnoel
Slides: http://slideshare.net/michaeltnoel
Travel blog: http://sharingtheglobe.com

42. Thank you to our sponsors