establishing environment best practices t12 brendan law

Establishing Environmental Best Practices

Brendan Law

[email protected]

@FlamerNZ

Flamer.co.nz/spag/

Title of presentation

2

Agenda

• Active Directory

• Service Accounts

• Database Platform

• Windows Platform

• Data Storage Planning

• Virtualisation

• Farm Topologies


3

Introduction

• The trick is finding the right balance between:

• There are often many solutions to the same problem

• Not meant as prescriptive guidance, but these are examples of how I have got it to work

• Keen to hear about others’ experiences

Ease of Usevs

Security

Manageability Performance


4

ACTIVE DIRECTORY


5

Active Directory

Corporate Intranet or Internal Only SharePoint

• Create Service Accounts in existing corporate domain

• Use a naming convention for easy identification

• Place accounts in Service Accounts OU

• Use strong passwords/password generator tool


6

Active Directory

Internet Publishing or External Collaboration

• Consider setting up a separate DMZ Domain

• Results in increased security

• Adds to administrative overhead (slightly)

• Set up one way trust so that internal users can authenticate with their existing credentials

– DMZ domain trusts Internal domain


7

Service Accounts

• Administrator - Install Account– Can be a domain admin, or in local administrators group on the box

– Setup can be run from your domain account

– Only used for the install and configuration of SharePoint

• SharePoint Service Account– Requires DBCreator and SecurityAdmin roles on the SQL Server

– Should be a standard domain user, not an administrator

– This is the account you put into the Configuration Wizard

– Runs the Central Admin App Pool, and Farm Services

• Search Crawl Account– This is the low privilege account used to crawl content on your web apps

– Needs no specific permissions, SharePoint will assign them for you

– Used for WSS Crawl and MOSS Crawl


8

Service Accounts

• Search Service Account– Used to run the Search Services (not used to access content during

crawls)

• Web Application Pool Accounts– A separate account should be used for each SharePoint Web Application

– At a minimum, the main content application pool credential should be different to the one running the Central Admin application pool

• Shared Service Provider Service Account– Used for the SSP specific services

• SQL Service Account– Used to run the MSSQLSERVER Service on your Database Server

Central Admin Shared Service Provider(s)

Main Web Application My Sites (if separate)


9

DATABASE PLATFORM


10

Database Platform

Awesome!

• New Dedicated SQL Server or Cluster

• 64 bit

• Plenty of RAM (8GB +)

• Physical Server

• Either 2005 or 2008

• Fast RAID 5 local disks or

• SAN attached DB Storage

• Maintenance Plans

• Well maintained

• Backups


11

Database Platform

Good

• New SQL Instance, or underutilised shared SQL Server

• Preferably 64 bit, or 32 bit

• Adequate RAM (4GB +) or more if Shared

• Physical or Virtual

• 2005 or 2008

• Fast mirrored local disks

• Or, if virtual, SAN attached DB Storage

• Maintenance Plans

• Backups


12

Database Platform

Bad

• Old or over utilised shared SQL server

• 32 bit

• Heavy page file utilisation due to inadequate RAM

• Old Physical server, or under resourced Virtual

• SQL 2000 or MSDE/SSEE

• Slow local disks, no redundancy

• No maintenance plans/not maintained

• No backups

• HUGE log files, drives running out of space

• No one takes responsibility for maintenance


13

WINDOWS PLATFORM


14

Patches and Service Packs

• Patch Windows!

• Make sure windows updates are running

• Test WSUS functionality

• Patch SQL Server– SQL 2000 SP4 required for install

– Another good reason to have a dedicated SQL install

• Slipstream latest MOSS Service Pack– SP2 patch has now been released

– Delete WSSSetup.dll from Updates directory


15

Partitioning

SharePoint Servers

• System Partition– C:\

– Where the Windows, Program Files folders live

– 30GB+

– Disk space usage can blow out during Service Pack installation

– Can be on a locally attached disk

• Data Partition– D:\

– Where everything else is, Logs, Indexes, Web Site Files

– Source/Install for storage of installed binaries

– Deployment folder for solution packages

– Should be on a SAN/RAID disk for performance


16

Partitioning

Database Servers

• System Partition– C:\

– Where Windows, and SQL application files live

– 30GB+

– Disk space usage can blow out during Service Pack installation

– Can be on a locally attached disk

• Data Partition– D:\

– Stores all the mdf files for SharePoint databases

– Ensure it is large enough to accommodate future growth

– Should be on SAN/RAID disk for redundancy


17

Partitioning

Database Servers (continued)

• Logs Partition– E:\

– Stores all the ldf files for SharePoint databases

– Needs to be fast, put on SAN/RAID disk or dedicated spindle

• Backup Partition– F:\

– Stores backups from your SQL maintenance plans

– Optional, if you have a separate backup server/storage method

– Needs to be redundant, put on RAID or Mirrored Partition


18

DATA STORAGE PLANNING


19

Data Planning

• What is the SharePoint site going to be used for?

• Set initial database size for planned growth in the next year

Internet Publishing Site File Share Replacement

• Performance• Redundancy

• Large Storage Needs• Multiple Content Databases


20

Content Databases

One

• For both Intranet Content and My Sites

• Easy to manage

• My Site content can cause database to expand

– If hosted in the same content DB

• Use quotas to manage site collection size


21

Content Databases

Split My Sites and Business Content

• Business content can be backed up separately

• My Site content database size is less of a concern

How:

• Create a new content database for my sites

• Set original content database to offline


22

Content Databases

Purpose based Content Databases

• For large document migration projects

• Or for differing backup/restore needs

• Increases database flexibility/scalability

• New site collections need to be created by an administrator


23

Maintenance Plans

• Set up on the SQL Server

• Easy automated database maintenance

• Requirements vary based on environment

• Optional if 3rd party backup software used


24

Sample Maintenance Plans

• Backup User Databases Daily– With clean up task

– .bak files should then be copied to secondary storage

• Backup System Databases Weekly– As these don't change as often as user databases

• Backup Transaction Logs hourly– If up to the hour restores are required

– Only for databases with full recovery model

• Reindex Databases Weekly– Helps with performance

– Shrinking databases causes file system fragmentation


25

Virtualisation

• Decide what to Virtualise– Web Front Ends

– Search Server

– Application Server

– Database Server

• Physical Infrastructure for Production

• Virtual for Test/Dev/Staging

• Backups are simplified, backup entire VHD/VMDK

• Restore as a group, at same point in time


26

FARM TOPOLOGIES


27

Topology – Basic Intranet

Best performance achieved on two servers:

• 1x Database Server

• 1x SharePoint Server

• Majority of my SharePoint installs have been in this configuration

• If database server is not well maintained, consider all in one server– But not a 'stand-alone' install


28

Topology - Search Optimised Intranet

Enables better performance for search and indexing

• 1x Database Server

• 1x Web Front End

• 1x Search Server

Search Server hosts SSP, Central Admin and a Web Front End

- Indexer can then be configured to crawl local web front end

Query role on Index Server Query role on Web Front End

-No propagation of Full Text Catalog-Search will need to be rebuilt to accommodate additional search servers

-Full Text Catalog propagation will occur-Useful if more search servers are planned


29

Topology – Extranet

Purpose: To collaborate with other organisations

• Host SharePoint Farm in DMZ

• Use forms based authentication

• Stand alone (windows service accounts)

• Or joined to DMZ Active Directory domain

• Publish through firewall with SSL


30

Topology – Extranet

Purpose: Publish Intranet to Remote Workers

• Host one Web Front End in DMZ

• Use ISA for external user authentication

– Terminate SSL on ISA too

• Need to allow traffic through the firewall

– SQL

– Active Directory


31

Topology - Internet Publishing

Two Farms:

• Firewall needs to be configured to allow deployment jobs between farms

Production SharePoint Farm Content Staging Farm

-This is the one the world sees-Separate AD Domain in DMZ-Performance optimisations turned on-Accepts content deployment jobs

-Used for updating content-Can be separate Web Application on Intranet Farm-Use content approval as needed


32

Topology – Load Balancing

• Multiple Web Front Ends/Query Servers to handle large volumes of traffic

– Use System Centre Capacity Planner to work out how many you’ll need

Web Front Ends can be easily built and added to the farm to handle extra load as needed


33

Topology – Load Balancing Methods

• DNS Round Robin– Simply switches the between servers in a IP address pool

– Can cause problems with session state (if needed)

• Windows Load Balancing– Good method for less sophisticated deployments

• Hardware Load Balancing– Need specialised hardware

– Can determine load on each server and route requests appropriately

– Best in high load/mission critical Internet applications


34

Topology – High Availability

Stretched Farm

• 1x SharePoint + 1x SQL Server located off site

• Needs to be connected via 1GB link

• Using standard tools, failover is manual

• Need to switch the SQL Alias

• DR Farm can also be used for load balancing


35

Topology – Disaster Recovery

SQL Mirroring

• Second SQL box has 'mirror' of SharePoint data

• Should production SQL fail, mirror takes over

• Failover can be automatic with a witness SQL server

• Doubles SQL Hardware requirements


36

Topology

Third Party Tools

• Disaster Recovery – NeverFail

• WAN Acceleration - Riverbed


37

Conclusion

• Many solutions to the same challenges

• Best practice is not to cut corners– We want our users to have the best possible experience

• Lots of information available– Twitter: @JoelOleson, @FlamerNZ, and many more

– Email Groups: OzMoss

– Blogs, Forums, Search

• Questions?

Thanks!Brendan Law

[email protected]

@FlamerNZ

Flamer.co.nz/spag/

establishing environment best practices t12 brendan law

Technology