BUILDING THE PERFECT SHAREPOINT

FARM

Michael NoelConvergent ComputingTwitter: @michaeltnoel

New Zealand SPUG TourAuckland, Tauranga, Napier, Wellington, Christchurch, NZ14-16 April, 2009

Michael Noel Author of SAMS Publishing titles “SharePoint 2007 Unleashed,” the upcoming

“Teach Yourself SharePoint 2007 in 10 Minutes,” “SharePoint 2003 Unleashed”, “Teach Yourself SharePoint 2003 in 10 Minutes,” “Windows Server 2008 Unleashed,” “Exchange Server 2007 Unleashed”, “ISA Server 2006 Unleashed”, and many other titles .

Partner at Convergent Computing (www.cco.com / +1(510)444-5700) – San Francisco, U.S.A. based Infrastructure/Security specialists for SharePoint, AD, Exchange, Security

Session Objectives And Agenda Examine various SharePoint farm architecture best

practises that have developed over the years Understand SharePoint Virtualisation Options Dive into specific details for each step in the build

process: Server Architecture Hardware Operating System SharePoint Binaries Installation Farm Installation/Adding to farm Shared Services Provider Configuration Farm Configuration

ARCHITECTING THE FARM

Various SharePoint Designs

All SharePoint roles and SQL Server on the same box

For very small environment without a lot of load

SQL contention with SharePoint

Easy to deploy, but highest potential for contention

NOTE: Only the smallest environments use SQL Server Express or SQL Embedded

Farm ArchitectureAll-in-One Farm

Dedicated SQL Server All SharePoint roles on

single box Disk IO contention

lessened by moving SQL off SP Server

Greater performance can be gained by breaking SharePoint roles onto separate servers

Farm ArchitectureDedicated SQL Database Server

2 Web/Query/Application /Central Admin/Inbound Email Servers

1 Dedicated Index Server (With Web role to allow it to crawl content)

2 SQL Standard Edition Cluster Nodes (Active/Passive)

Smallest highly available farm (loss of any one server will not affect functionality)

Farm ArchitectureSmallest Highly-Available Farm

Farm ArchitectureScalable Farm Multiple Dedicated Web Role Servers Multiple Dedicated Query Servers Multiple Dedicated Application Servers Dedicated SharePoint Central Admin Server(s) Single Index Server (per Shared Services Provider) Multiple node or multiple instance SQL Server Enterprise Edition

Cluster(s)

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

Virtualised Farm ArchitectureCost-effective Virtual Environment

High-Availability across Hosts

All components virtualised

Uses only two Windows Ent Edition Licenses

Virtualised Farm ArchitectureFully Redundant Farm with only Two Servers

Highest transaction servers are physical

Multiple farm support, with DBs for all farms on the SQL cluster

Only five physical servers total, but high performance

Virtualised Farm ArchitectureBest Practise Mixed Virtual/Physical Config with High Performance

Multiple Hosts – Scale Out

Content Database and Site Collection PlanningDistribute by Default

Start with a distributed architecture of content databases from the beginning, within reason (more than 50 per SQL instance is not recommended)

Distribute content across Site Collections from the beginning as well, it is very difficult to extract content after the face

Allow your environment to scale and your users to ‘grow into’ their SharePoint site collections

Farm1

home.companyabc.com

/dept(Mg Path)

mysite.companyabc.com SP Central Adminssp1.companyabc.com

ABC_Farm1_SSP1_Content ABC_Farm1_SPCA_ContentABC_Farm1_Dept1_Content ABC_Farm1_Dept3_Content

ABC_Farm1_Dept2_Content

ABC_Farm1_Config

ABC_Farm1_Root_Content

AdditionalDeptartmental

Site Collections,each withSeparatecontent

databases

ABC_Farm1_MySite2_Content

ABC_Farm1_MySite3_Content

ABC_Farm1_MySite4_Content

ABC_Farm1_MySite5_Content

ABC_Farm1_MySite6_Content

ABC_Farm1_MySite7_Content

ABC_Farm1_MySite8_Content

ABC_Farm1_MySite9_Content

ABC_Farm1_MySite10_Content

ABC_Farm1_MySite1_Content

ABC_Farm1_SSP1

ABC_Farm1_Search

/dept1 /dept3/dept2

Shared Services Provider (SSP1)S

am

ple

SP

Log

ical A

rch

itectu

re

HARDWARE

Planning for the farm

Hardware Planning ConsiderationsDisk, Memory, and Processor

SQL Database role requires a great deal of space, especially if versioning is turned on in Document Libraries. Don’t underestimate!

Index and Query servers also need hard drive space to store the Index files, which can be 5%-30% of the size of the items being indexed.

The more memory and processor cores that can be given to SharePoint the better, in the following priority: Database Role Index Role Web/Query Role

Hardware Planning ConsiderationsVirtualisation

Windows Server 2008 Hyper-V is an excellent option, and can save money.

Microsoft supports third party if they are a member of the SVVP (KB 897615), this includes VMware and Citrix XenServer. There are some limitations, consult the KB article.

Not all roles are the best candidates for virtualisation, depending on the level of disk I/O that is expected. The best candidate for virtualisation is the Web/Frontend, followed by Query, Application, Index, and finally SQL.

OPERATING SYSTEM

Laying the foundation

Operating System Best practisesVersions

Highly recommended: Windows Server 2008 for security, performance (client/server traffic improvements), and ease of setup

x64 bit also very highly recommended (Next version of SharePoint is x64 bit only.

Enterprise Edition of Windows only required for very large SQL instances (More than two cluster nodes, high transaction volume, etc.) Standard edition of Windows is adequate in nearly all other cases.

Operating System Best practisesSQL Server

SQL Server 2008 Recommended, particularly if you have high security requirements, as it allows for transparent encryption of databases

SQL Server 2005 also fully supported Enterprise edition of SQLonly required for more

than two nodes in a cluster, Asynchronous database mirror replication, and/or greater than 32GB RAM

Separate Reporting Services server may be required for intensive reporting

Operating System Best practisesInstallation: SQL Server

Install the defaults for Windows Server 2008

SQL Server Install SQL Server

2005/2008 Install any service

packs and updates (i.e. SQL 2005 SP2 / SQL 2008 SP1)

Open port 1433 on the Windows Firewall.

Operating System Best practisesInstallation: SharePoint Server

Install the defaults for Windows Server 2008

SharePoint Servers Add the ‘.NET

Framework 3.0 Features’ from the Add Features wizard

Default Windows Firewall settings will work for front-ends

SHAREPOINT INSTALLATION

Adding the SharePoint binaries

SharePoint InstallationService Accounts Never use a single account for all services unless it’s a test

farm. At a minimum, create the following accounts:

SQL Admin Account Installation Account (Local admin rights on SP servers) SharePoint Farm Admin (Requires SQL DBCreator and SQL Security

Admin on SQL box) Search Admin (Requires local admin rights on any Query or Index

servers Default Content Access Account (Read-only access to all indexed

locations) Application Pool Identity Account (at least one, can use multiple for

each App pool.) It is critical for security that this isn’t the farm admin account.

SharePoint InstallationInstallation Process For most flexibility, choose

‘Complete’ Installation, even if not installing all of the roles on the server. This will allow for the addition of roles in the future as needed.

Be sure not to select ‘Stand-Alone’, unless you plan on having a very small farm with a limited database (SQL Server Express)

SharePoint InstallationInstallation Process Highly recommended to

choose the final destination for the Index/Query to live (i.e. if it’s on a different drive, enter that during installation). It’s difficult to change index location later.

Remember, after installing the binaries, the server is not a farm member yet…it can be added to any farm. Good concept to use to pre-stage servers.

SharePoint InstallationCommand-line Installation of SharePoint

Good to understand how to install SharePoint from the command-line, especially if setting up multiple servers.

Allows for options not available in the GUI, such as the option to rename the Central Admin Database to something easier to understand.

Use SETUP, PSCONFIG and STSADM to script the install process, check online blogs for details.

CREATING A FARM

Using the Configuration Wizard or PSCONFIG

Creating the FarmRunning the Config Wizard to Install Servers Consider using an easy to

remember port for the Central Admin service (i.e. 8888)

You are welcome to change the Config Database name to match a common naming convention

Your database access account is the SP Service account, which only needs DBCreator and Security Admin rights on SQL. Don’t give it more!

Run the wizard on additional servers as necessary

Creating the FarmUsing a SQL Alias Do yourself a HUGE favor

and don’t forget to use a SQL Alias when creating the SQL Config Database. For example, if your SQL server name is ‘SQLSERVER1’, use something like ‘SPSQL’ to connect, and have DNS point to the proper server location. This makes it MUCH more flexible.

SHARED SERVICES PROVIDER

Best Practises

Reviewing SharePoint ArchitectureUnderstanding the Shared Services Provider A Shared Services Provider coordinates services that are used by

multiple servers in a farm, including: AD Profile Import Enterprise Search (Including Index) Business Data Catalog Audiences Excel Services My Sites Usage Reporting

There can only be one Index per SSP Some scenarios why multiple SSPs can be created:

If needing to separate Indexes from multiple content sources (Security reasons) Unique search required for different branches of the organisation If needing to separate My Sites content, including custom settings Global multi-farm SharePoint deployments

SSP Web ApplicationsWeb Application Best practises

Recommended to create multiple Web Applications, even for smaller farms, i.e.: SP Central Admin Web App ssp1.companyabc.com mysite.companyabc.com home.companyabc.com

Much more flexible approach to use dedicated web applications. Mysite and the root SP site can be combined in certain circumstances, but is not as flexible.

SSP Web ApplicationsWeb Applications Best practises Consider using unique

hosts headers when creating the web applications, even if you will separate by IP later. This helps when provisioning new web front-ends.

For the SSP and Central Admin Web Apps you can use NTLM for convenience, but know that post SP2 it is now supported to use Kerberos on them.

When creating any Web Applications for Content, USE KERBEROS. It is much more secure and also much faster as the SP server doesn’t have to keep asking for auth requests from AD.

Kerberos auth does require extra steps, which makes people shy away from it, but once configured, it improves performance and security considerably.

KerberosBest practise: Enable Kerberos!

Kerberos in 4 ‘Easy’ StepsStep 1: Create the Service Principal Names Use the setspn utility to create Service Principle

Names in AD, the following syntax for example: Setspn.exe -A HTTP/mysite.companyabc.com DOMAINNAME\

MYSiteAppAccount Setspn.exe -A HTTP/mysite DOMAINNAME\MYSITEAppAccount Setspn.exe -A HTTP/home.companyabc.com DOMAINNAME\

HOMEAppAccount Setspn.exe -A HTTP/sp DOMAINNAME\HOMEAppAccount

On all SP Computer accounts and on the Application Identity accounts, check the box in ADUC to allow for delegation. In ADUC, navigate to the

computer or user account, right-click and choose Properties.

 Go to the Delegation tab Choose Trust this

user/computer for delegation to any service (Kerberos)

Kerberos in 4 ‘Easy’ Steps Step 2: Allow User and Computer Accounts to Delegate

On Each SharePoint Web Front-end: Go to Start – All Programs –

Administrative Tools – Component Services

Navigate to Component Services – Computers – My Computer

Right-click My Computers, choose Properties

Choose the Default Properties tab

Change Default Impersonation Level to Delegate

Click OK

Kerberos in 4 ‘Easy’ Steps Step 3A: Set default Impersonation Level in Component Services

From Component Services snap-in on each web role: Navigate to Component Services –

Computers – My Computers – DCOM Config

Right-click on IIS WAMREG Admin Service and choose Properties

Select the Security tab Under Launch and Activation

Permissions, click the Edit button Add the application pool account

and check the Allow box for Local Activation on each account.

Click OK, OK, and close Component Services

Kerberos in 4 ‘Easy’ Steps Step 3B: Set IISWAMREG Permissions

Windows Server 2008 front-ends requires the ApplicationHost.config file to be modified to contain the following string: <windowsAuthentication enabled="true" useKernelMode="true"

useAppPoolCredentials="true">

Kerberos in 4 ‘Easy’ Steps Step 4 (Windows 2008 only): Edit ApplicationHost.config file

CONFIGURING THE FARM

A smattering of best practises

Configuring the FarmBest practises For Email enabled content, create a dedicated OU for

Email enabled contacts and distribution lists and give the SP Admin account rights to create and modify contacts and groups in that OU.

Use the Index server (if a separate role) as a dedicated server for crawling content, to do this you have to turn on the web role, however.

Don’t forget to configure an NLB VIP for inbound Mail using the SMTP service in a multi-server environment.

You can use multiple web applications that are ‘extended’ if you need to provide multiple access mechanisms to the same content.

Configuring the FarmBest practises

Don’t forget Alternate Access Mappings if connecting to the content in more than one way (i.e. https://home.companyabc.com vs. just http://home)

If using SSL on a web app, it is recommended to have a dedicated IP address, not just a host header

Don’t forget to install Antivirus (MS Forefront Security for SharePoint recommended)

Don’t forget a comprehensive backup solution (MS System Center Data Protection Manager (DPM) 2007 recommended)

For indexing PDFs, consider a 64bit iFilter like FoxIT

Key Takeaways Use multiple service accounts, definitely don’t

mix Application Pool identity accounts with the farm admin acccounts

Use Kerberos for any user facing web application Use a SQL Alias for greatest flexibility A five server farm is the smallest that is highly

available Separate the DB role from the SP server if you can

For More Information SharePoint 2007 Unleashed (SAMS Publishing) (

http://www.samspublishing.com) SAMS Teach Yourself SharePoint 2007 in 10

Minutes (http://www.samspublishing.com) Microsoft ‘Virtualizing SharePoint Infrastructure’

Whitepaper (http://tinyurl.com/virtualsp )

Thanks for having me at your User Group in beautiful New Zealand!

Questions?

Michael NoelTwitter: @michaeltnoel

www.cco.com