This document discusses strategies for building different types and sizes of SharePoint farms to meet varying needs. It addresses factors to consider like capability, performance, reliability, scalability, user experience, security and cost. The key aspects are defining requirements and goals, then designing an optimal farm topology with the right server roles, sizing, virtualization plan, high availability strategy and disaster recovery approach. The focus is on a well planned, documented and tested implementation of the "perfect" SharePoint farm for each organization's unique needs.

1. Building the Perfect SharePoint Farm 2011

2. Attach the ISO Run the installer Let’s Get Started

3. Web Front End Service Application Server SQL Server External Services SharePoint Server Roles

5. Everything on one server

6. Only for Development or similar use

7. Can run on Windows 7Single Server Farm

9. WFE and Service App layer running on the same box

10. Recommended for small workgroupsSmall Farm

12. WFE and Service App layer running on individual servers

13. Can handle large amounts of users and content

14. No RedundancyMedium Farm

16. WFE and Service App layer running on same servers (but two of them)

17. Can handle larger amounts of users, but App Layer impacts performance

18. Some RedundancyMedium Farm – Option 2

20. Multiple Service App Layers

21. Clustered SQL Server

22. No Single Point of FailureLarge Redundant Farm

23. How can one, or even four, farm architectures satisfy every need? The “Perfect” SharePoint Farm?

24. We need to define perfection Capability Performance Reliability Scalability User Experience Security Cost

25. Document Management Records Management Web Content Management Social Collaboration BI Platform Enterprise Messaging Capability – What are we trying to accomplish?

26. Performance – How fast does it need to be? Is there an established SLA, and should there be? Page Load vs Transaction time (what can we directly control) Average User Load Total users * % Concurrent Users / Time Per request

27. Reliability is expensive No really…its expensive Hardware (more than doubled Support staff increase Higher level of competency of staff Challenge it early and often Reliability – Are you sure you can afford it?

28. Scalability – What is my growth curve? Establish metrics on your farm and stay on top of them Know scaling options Server size Server numbers Server Role WFE – users Service App – usage SQL – Size and use of content

29. Needs and Wants Goals, Motivations & Triggers Obstacles & Limitations Tasks, Activities & Behaviors Geography & Language Environment & Gear Work Life and Experience User Experience – The mythical user

30. Security – Information wants to be free! Encrypt your data – yes, even internal communication Segment SharePoint on a dedicated VLAN Use reverse proxy servers (TMG) Use SSL (but off-load it) Use dedicated Admin accounts

31. Know your licensing options Foundation (free) Standard v Enterprise Internet Sites Don’t forget to include all other server costs Windows/SQL/TMG/etc Hardware costs Servers Routers Cost – Plan for now and the future

32. The secret sauce is planning What roles do I need in my farm? How “big” do those roles need to be? How do we put it all together

33. SharePoint Roles Revisited Web Front End Server Very similar to MOSS 2007 Primary scale component is number of users connecting 8GB RAM, 4 “cores”, 80GB HD SQL Server Clustered or other HA technology Can have multiple instances to share load Performance is critical to Farm 16-64GB of RAM/8+ “cores”, 80GB HD + Data

34. SQL Considerations Alias your server (SQL Alias or DNS) Size of content DB determines minimum RAM Medium (< 4TB of Content) -> 32GB RAM Large (>4TB of Content) => 64GB RAM Disk Performance is critical Tune the SAN for optimal performance by use RAID 10 is best, RAID 5 is OK Data, Log, and Temp DB all on separate LUNS and Logical Disks Ensure that SAN NIC isn’t saturated

35. Service Application Servers Automatically scale and load balance Can partition services to specific servers Search is very scalable, but very complex Crawl Servers Can have multiple servers crawling your data Query data sent directly to the Query servers (not on crawl) Query Servers Can create multiple partitions 10 Million items is upper limit for a partition Can have active and passive fail-over partitions Query size is estimated at 10% of crawled content (usual smaller)

36. Simple (Yeah Right) Search Topology

37. What can we virtualize? WFE Service App SQL What should we virtualize? WFE Service App SQL? Allows us to dynamically manage Farm as needed by requirements Snapshots are your friend Virtualization – Problem or Solution?

38. High Availability, DR and Virtualization Plan for emergencies Recovery Time Objective Recovery Point Objective Prevent single point of failure Consider Virtual DR Also plan for effort to recover from fail-over

39. Can the Cloud Save Us? Transfers Risk to Cloud Provider Servers Network Patches Backups Reduces “dark” hardware costs Can be cheaper, or more expensive (shared vs private cloud)

40. Its all so complex

41. Define our “Perfect” Farm Capability Performance Reliability Scalability User Experience Security Cost

42. Design our “Perfect” Farm Server Roles Server Size & Number Virtualized Components Availability Disaster Recovery Don’t forget Test Farm, and Development Farm

43. Build the “Perfect” Farm Stick to the plan Ensure all the pre-reqs and patches are installed Script the install AutoSPInstaller.Codeplex.com (other exist as well) Snapshot everything before you start Snapshot after install Take lots of screen shots for documentation