The document discusses Microsoft SharePoint server farm topologies and sizing recommendations. It covers factors to consider like availability, capacity, performance, and organizational requirements. It provides guidance on the number of servers, databases, web applications, and other components for small, medium and large farm designs based on the number of users and workload. It also discusses virtualization support and recommendations.

1. Geoff Evelyn [email_address]

2. What is the Microsoft supported definition of: Small Farm? Medium Farm? Large Farm? Forget the old definitions! They do not apply to Microsoft Office SharePoint Server 2007 topologies.

3. Availability Capacity Performance Organisational requirements Differing availability requirements / SLAs Regulatory / data segregation requirements Functional requirements Licensing Cost

4. Increasing complexity and cost

5. Review the TechNet planning guides Plan for system requirements http://technet2.microsoft.com/Office/en-us/library/0ed0b44c-d60d-4b85-87de-19065d9688351033.mspx?mfr=true Design server farms and topologies http://technet2.microsoft.com/Office/en-us/library/0ed0b44c-d60d-4b85-87de-19065d9688351033.mspx?mfr=true Plan for performance and capacity http://technet2.microsoft.com/Office/en-us/library/0ed0b44c-d60d-4b85-87de-19065d9688351033.mspx?mfr=true Logical architecture components http://technet2.microsoft.com/Office/en-us/library/0ed0b44c-d60d-4b85-87de-19065d9688351033.mspx?mfr=true

6. Document customer base # users, usage profiles, locations Gather requirements Functionality Availability Plan for capacity Plan for performance Research and document design constraints

7. SharePoint Topology Planning

8. Can contain up to 5 million items Split content up using folders Try to not have more than 2000 items/folders at any one level in the hierarchy Not a hard limit Utilise indexed columns and custom views Consider Usability Search Relevance Size of the content database

9. 250,000 sites per collection / 50,000 collections per web application Nest sites to reach 250,000 (2000 / level) Site enumeration performance drops at 2000 sites Consider Usability & Search Relevance Size of collection / content databases Operations like export / import

10. Max size based on operations / SLAs Most customers: 50GB – 250GB Recommend no more than 100 per web application (based on SQL server spec) Move to multiple SQL instances to increase Try to group site collections of similar size and function into shared content databases Site collections cannot span multiple DBs Content deployment requires multiple DBs STSADM can target content DBs / UI cannot* New SP1 STSADM command “mergecontentdb” can be used to merge and split content dbs

11. 99 per Shared Service Provider Consider server resources (10 per farm realistic) 1-2GB memory typical Sharing app pools can decrease utilisation 10 > will probably require multiple child farms Consider Top level URL requirements / SSL Functional requirements (ex: self service site creation) Process isolation

12. 3 per farm, 20 max Server resources are a big factor Why multiple SSPs? Differing functional requirements Multiple administrative groups Multiple index servers / multiple indexes * In most scenarios, one SSP is all you need

13. No theoretical limit when isolated (running own SSP) Consider CapEx/OpEx Can consume a parent farm’s SSP or host an SSP for other farms to consume 99 web apps per SSP apply Can only share 1 SSP

14. SharePoint Topology Planning

15. “ Basic Install” – all services running on a single box Pros Simple “one click” install Inexpensive Includes SQL Express Great for evals/prototypes Cons No direct upgrade to multi-server topology Availability Scalability (SQL express) Performance

16. Single MOSS server (complete install), separate SQL backend Pros Better scalability / performance with SQL standard / enterprise Intensive I/O and memory consumption moved offloaded Added SQL features: SRS, AS Cons Availability MOSS performance Scalability

17. Pros SQL high availability Cons MOSS availability / perf More complex install (Cluster setup / shared disk) Questions A/A or A/P? Clustering or Mirroring?

18. Pros: Better MOSS performance Increases scalability Better availability Cons: Only one query server Unbalanced resource utilisation

19. Typical “starter” topology Pros: Balanced resource consumption Multiple query services Cons: Can’t cluster / load balance indexer Increasing storage requirements

20. Pros: Increased capacity / performance Cons Lots of storage Increased OpEx Note Diminishing returns (4-5 WFE / SQL) Increases auth traffic (3-4 wfe / AD w/ NTLM)

21. Pros Potential increase in query performance Notice Multiple SQL clusters to support greater number of WFEs

22. Indexer is configured to crawl only 1 WFE (outside the LB) Pros: Index traffic doesn’t consume user WFE server resources – better perf Cons: Single point of failure Potential increase in crawl time Host file maintenance

23. Indexer running web service and configured to index itself Pros Less crawl traffic on the wire Potential increase in index performance Cons Indexer server resources split between indexing operation and WFE operation

24. Services such as Excel Services, Document conversions, etc can be ran on dedicated hardware Pros Better performance for WFE and application servers Cons More complicated configuration Increased costs

25. Parent farm provides shared services to child farms (must be on LAN not WAN*) Child farms may have their own SSP (excel services) Pros Massive scalability / performance Targeted performance tuning Isolation Franchise model Cons Complex setup Complex backup / restore – increased Cost Child farms cannot administrate shared service / differing SSP configuration Note: May or may not have multiple SQL clusters

26. Typical example of multi-farm topology Challenges AuthN / SSO experience for internal users Content Synchronisation?

27. Put’s the “service” closer to the customer = Better user experience Challenges Centralised administration Search Architecture Two way synchronisation Profile synch Global deployment of MySites

28. Recommendations: Improve the network issues before jumping to multiple farms Look to third party tools to provide additional functionality in global scenarios Admin: Quest, Echo Tech, DeliverPoint Replication: Syntergy, Echo Technologies, iOra ,Doubletake Network Acceleration: Citrix, Cisco, Packeteer, Certeon Offline -Colligio, iOra

29. IT Org capability? Third party components? 014 strategy / timeline? Why 64 bit Performance e Scalability (> 2GB)

30. Mixed mode? Longer term – recommendation is not to mix 64/32 bit in the same tier Short term – can mix (example 32 -> 64 upgrade)

31. IT Org capability? Third party components? 014 strategy / timeline? Why 64 bit Performance Scalability

32. Recommendation: SQL – 64 bit highly recommended Index - 64 bit if you can – check filter / protocol handler availability WFE – 64 bit for better scalability (More web applications)

33. The first server in the farm will host the CA site CA can be moved – Config Wizard PSConfig – adminvs Best location? It depends  Load Balance? It depends 

34. Existing Infrastructure AD / DNS / Network Authentication method (Kerb/NTLM) can have a big impact on AD Storage DAS / SAS / SAN Backup / Restore Archive Disaster Recovery Monitoring Proxy Servers / Firewalls

35. 1. User access (Web traffic from browsers to web servers): TCP Port 80 (HTTP) SSL Port 443 (HTTPS) Custom Port(s) – (Web application zones can be configured to use any available port) 2. Search Query/Index Propagation: Named Pipes, which requires File and Printer Sharing NBT —UDP Port 137,UDP Port 138, TCP Port 139 Direct-hosted SMB —TCP/UDP Ports 445 3. MOSS Web Services: Both default to: TCP 56737 TCP 56738 (SSL) Customizable using stsadm -setsspport 4. SQL Communications: Default Instance: TCL Port 1433 (default), can listen on custom (assigned) port Named Instances: Listen on random TCP ports by default, can listen on custom (assigned) ports 5. Search Indexing: TCP Port 80 (HTTP) SSL Port 443 (HTTP) Custom Port(s) – can index any port based on content source rules (for instance, file share crawls use SMB (TCP/UDP 445 ) 6. SSO Communications Communications with encryption key server requires RPC: TCP 135 (RPC endpoint mapper) Random high ports OR Assigned range of static ports

36. http://support.microsoft.com/kb/909840 Microsoft fully supports Virtual Server 2005 R2 We provide commercially reasonable support for VMWare if a customer is having a SharePoint issue on VMWare we will go to reasonable lengths to address it. If it is necessary support will ask to repro the issue on a hardware based machine for further investigation We do set expectations up front that it is not officially supported in the sense that we would provide a Hotfix if the issue was caused by running on VMWare Most issues encountered in a VW environment are issues you would see on physical servers

37. What to virtualise (non production) Local dev boxes, build machines, integrated dev environments, “smoke test” environments POC / prototypes Try not to virtualise performance testing environments Production WFE are good candidates Query servers potentially if you expect a very light search load (which isn’t the case most of the time) Definitely not the SQL servers! Remember to be realistic with your VM configuration

38. Use a tool like the HP sizing and Configuration Tool or System Center Capacity Planner 2006* http://h71019.www7.hp.com/activeanswers/Secure/548230-0-0-0-121.html Start with a basic 5 server physical topology – provides good performance and availability. Scales out easily Start with a small user population (pilot). Ramp new users on in a controlled manner – monitor and scale out as needed Use the out of box site definitions / fabulous 40 templates to get started Let the organisation mature, then initiate an IM redesign