There are a myriad number of approaches to design and architecture of SharePoint servers, not all of which are ideal, however. Since the design of a SharePoint environment is subsequently critical to its performance and functionality, it is critical to understand what the best practices around SharePoint infrastructure design are. SharePoint architects need to be aware of the various installation options, the differences between SharePoint search architecture models, how and when to virtualize SharePoint, and ways to optimize the SQL Database tier of SharePoint. In addition, integrating SharePoint On-Premises with cloud models such as SharePoint Online and Enterprise Social environments such as Yammer has its own set of infrastructure challenges. 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 On-Premises and/or hybrid cloud environments. In addition, a close look at new models at the data tier such as highly available farms that use SQL 2014/2012 AlwaysOn Availability Groups 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. • Understand how cloud and hybrid models affect SharePoint On-Premises Infrastructure and how to integrate them easily • Examine new High Availability strategies with SharePoint that take advantage of the aggressive SLAs provided with SQL 2014/2012 AlwaysOn Availability Groups • Learn simple ways to get better performance out of an existing SharePoint environment, with tips and tricks for the SharePoint data, web, and service application tiers

1. SharePoint Infrastructure Tips and Tricks for
On-Premises and Hybrid Cloud Environments
Michael Noel
Convergent Computing (CCO)
www.cco.com
925-933-4800

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. SharePoint 2013
Infrastructure Overview

4. SharePoint 2013 Infrastructure Overview
Software/Hardware Requirements
• Windows Server 2008 R2 SP1, Windows Server 2012, or
Windows Server 2012 R2 (With SP 2013 SP1)
• SQL Server 2008 R2 w/SP1, SQL Server 2012, or SQL Server 2014
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

5. SharePoint 2013 Infrastructure Overview
Changes in Service Applications and New Service Applications
• 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

6. SharePoint 2013 Infrastructure Overview
Distributed Cache Service
• 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

7. SharePoint 2013 Infrastructure Overview
Request Management (RM)
• 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

8. SharePoint 2013 Infrastructure Overview
User Profile Sync – Three Options for Deployment
• 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

9. SharePoint 2013 Infrastructure Overview
Claims-based Authentication - Default
• 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

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

11. SharePoint 2013 Infrastructure Overview
Search – FAST Search now included
• New Search
architecture (FAST
based) with one
unified search
• Personalized search
results based on
search history
• Rich contextual
previews

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. Architecting the Farm
• 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

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

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

18. Architecting the Farm
• 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
Large SharePoint Farms

19. Cloud and Hybrid
Scenarios

20. www.cco.com
Cloud and Hybrid Scenarios
One-way Outbound Topology

21. www.cco.com
Cloud and Hybrid Scenarios
One-way Inbound Topology

22. www.cco.com
Cloud and Hybrid Scenarios
Two-way Inbound/Outbound Topology

23. Identity Management in Hybrid Mode
• Single Sign On possible between environments using
Azure Active Directory Synchronization Tool
• Azure Active Directory Connection Required, regardless
of SSO or non SSO (non-SSO just synchs passwords)
• Consider the use of the OnRamp for Office 365 toolkit
(https://onramp.office365.com/OnRamp/)
• Server to Server Authentication also required (Certs)
www.cco.com

24. SharePoint Virtualization

25. SP Server Virtualization
Sample 1: Single Server Environment
 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

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

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

28. SP Server Virtualization
Scaling to Large Virtual Environments

29. Virtualization of SharePoint Servers
Virtualization Performance Monitoring
• 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

30. Data Management

31. Data Management
Sample Distributed Content Database Design

32. Remote BLOB Storage (RBS)
Data Management
• Can reduce the size of Content DBs, as upwards of 98% 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 as it increases scalability

33. SQL Database
Optimization

34. SQL Server Optimization
DB-A
File 1
DB-B
File 1
Volume #1
Multiple Files for SharePoint Databases
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

35. SQL Server Optimization
Multiple Files for SharePoint Databases
• 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.

36. SQL Database Optimization
SQL Maintenance Plans
• Implement SQL Maintenance Plans!
• Include DBCC (Check Consistency) and either Reorganize Indexes or Rebuild
Indexes, but not both!
• 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…)

37. High Availability and Disaster Recovery

38. 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
HA and DR

39. AlwaysOn Availability Groups in SQL 2012/2014
HA and DR

40. Creating SQL 2014 AOAGs
Demo

41. Network Load Balancing
HA and DR
• 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)

42. Security and
Documentation

43. • 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
• Rights Management
Five Layers of SharePoint Security
Security

44. • 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
Document SharePoint

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