1. The ‘Ultimate’
SharePoint
Infrastructure Best
Practices Session
Michael Noel - CCO

2. Michael Noel
• Author of SAMS Publishing titles “SharePoint 2013 Unleashed,” “SharePoint 2010
Unleashed”, “Windows Server 2012 Unleashed,” “Exchange Server 2013
Unleashed”, “ISA Server 2006 Unleashed”, and a total of 19 titles that have sold
over 300,000 copies.
• Partner at Convergent Computing (www.cco.com) – San Francisco, U.S.A. based
Infrastructure/Security specialists for SharePoint, AD, Exchange, System Center,
Security, etc.

3. What’s new in
Infrastructure for
SharePoint 2013

4. • 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
What’s new in Infrastructure for SharePoint 2013
Software/Hardware Requirements

5. • 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
What’s new in Infrastructure for SharePoint 2013
Changes in Service Applications and New Service Applications

6. • 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
What’s new in Infrastructure for SharePoint 2013
Distributed Cache Service

7. • 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
What’s new in Infrastructure for SharePoint 2013
Request Management (RM)

8. • 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) Synchronization, allows for complex
scenarios – Larger clients will appreciate this
What’s new in Infrastructure for SharePoint 2013
User Profile Sync – Three Options for Deployment

9. • 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
What’s new in Infrastructure for SharePoint 2013
Claims-based Authentication - Default

10. • Stores new versions of documents as ‘shredded
BLOBs that are deltas of the changes
• Promises to reduce storage size significantly
What’s new in Infrastructure for SharePoint 2013
Shredded Storage

11. • New Search
architecture (FAST
based) with one
unified search
• Personalized
search results
based on search
history
• Rich contextual
previews
What’s new in Infrastructure for SharePoint 2013
Search – FAST Search now included

12. ARCHITECTING THE FARM

13. Web
Service Apps
Data
Architecting the Farm
Three Layers of SharePoint Infrastructure

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

15. • 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
Architecting the Farm
Smallest Highly Available Farm

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

17. • 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
Architecting the Farm
Ideal – Separate Service App Farm + Content Farm(s)

18. • Multiple Dedicated
Web Servers
• Multiple Dedicated
Service App Servers
• Multiple Dedicated
Query Servers
• Multiple Dedicated
Crawl Servers, with
multiple Crawl DBs to
increase parallelization
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
Architecting the Farm
Large SharePoint Farms

19. SharePoint Virtualization

20.  Allows organizations 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
SP Server Virtualization

21.  High-
Availability
across Hosts
 All
components
Virtualized
Sample 2: Two Server Highly Available Farm
SP Server Virtualization

22.  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
SP Server Virtualization

23. • Processor (Host Only)
– <60% Utilization = 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% Utilization = Good
– 41%-64% = Caution
– >65% = Trouble
• Network Latency - Output
Queue Length
– 0 = Good
– 1-2= OK
– >2 = Trouble
Virtualization of SharePoint Servers
Virtualization Performance Monitoring

24. Data Management

25. Sample Distributed Content Database Design
Data Management

26. SQL 2012 AlwaysOn Availability Groups

27. AlwaysOn Availability Groups in SQL 2012
HA and DR

28. Demo
Creating SQL 2012 AOAGs

29. Michael Noel
Twitter: @MichaelTNoel
www.cco.com
Slides: slideshare.net/michaeltnoel
Travel blog: sharingtheglobe.com
Pre-order SharePoint 2013 Unleashed:
tinyurl.com/sp2013unleashed

30. Michael Noel
Twitter: @michaeltnoel
facebook.com/michaelnoel
linkedin.com/in/michaeltnoel
Instagram: SharingTheGlobe
Travel blog: SharingTheGlobe.com
Joel Oleson
Twitter: @joeloleson
facebook.com/joleson
linkedin.com/in/joeloleson
Instagram: joeloleson
Travel blog: TravelingEpic.com
Paul Swider
Twitter: @pswider
facebook.com/pswider
linkedin.com/in/pswider
Instagram: pswider
Blog: paulswider.com