SharePoint 2010 best practices for infrastructure deployments SharePoint Saturday NZ


Published on

This session cover best practices for ensuring that your core SharePoint infrastructure layer has been deployed correctly. The session is geared towards SharePoint infrastructure administrators and architects who will be managing a SharePoint deployment.

Published in: Technology
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

SharePoint 2010 best practices for infrastructure deployments SharePoint Saturday NZ

  1. 1. SharePoint Saturday NZBest Practices - for SharePoint 2010 Infrastructure Deployments December 10th 2010 Patrick Harkins – Senior SharePoint Architect, SharePoint Consultant
  2. 2. Who Am I• SharePoint Elite (Infrastructure) – First in the world• SharePoint 2010 IT Pro Ignite Trainer – For New Zealand••
  3. 3. Session Agenda• SharePoint Infrastructure 101 – Technologies – Considerations• Before Installation Begins – SQL Recommendations – OS Recommendations – SharePoint Recommendations• Installation Best Practice• Post Installation
  4. 4. SharePoint Infrastructure 101
  5. 5. Technologies• 3 Distinct Application Technologies – IIS (Internet Information Services) – MSSQL (Microsoft SQL Server) – SharePoint• 3 Distinct Operational Technologies – AD (Active Directory) – DNS (Domain Name System) – OS (Operating System)
  6. 6. SharePoint - The Technology Layer User Profiles ForeFront Configuration and Messaging and Content Identity .Net Framework and Service Data RecoveryOrganisational Communication Databases Manager Databases Information Exchange Internet Information Server + Active Directory SQL Server 2005/2008 (x64) Services Lync Server
  7. 7. Considerations• IIS Version (based on OS version)• MSSQL Version – Standard vs Enterprise – 2005 vs 2008 vs 2008 R2 – Standalone vs Cluster• SharePoint – Foundation vs Standard vs Enterprise• AD (Active Directory) – Domain Functional Level (relates to Kerberos)
  8. 8. Considerations cont.• OS (Operating System) – 2008 x64 vs 2008 R2 – Standard vs Enterprise• Requirements – Business Requirements – Information Architecture – End User – Development
  9. 9. Before Installation Begins
  10. 10. SQL Recommendations• SQL Server (64bit only) – SQL 2008 R2 – SQL 2008+SP1+CU2 (or greater) • Do not use CU3 or CU4, Use CU2, CU5, or a later CU than CU5. – SQL 2005 w/SP3 – supported / not recommended for large deployments
  11. 11. OS Recommendations• OS (64bit only) – Windows Server 2008 R2 – Windows Server 2008+SP2• Server capacity – SQL and SharePoint?• Virtualisation vs Physical
  12. 12. SharePoint Recommendations• Naming Conventions – Service/Managed Accounts – Databases – Web Applications/Application Pools – Service Applications/Application Pools
  13. 13. Installation Best Practice
  14. 14. Some Best Practice• Naming Convention – Database, Service Accounts, Service Applications – Web Applications/Pools• Script the Installation and Configuration• Use of SQL Alias• Use of DNS records (A-Records)• Use of Port 80 & 443 for Web Applications• Kerberos vs NTLM• SQL Database Maintenance
  15. 15. Naming Convention – Service AcDescription Account name CommentsSharePoint Setup Account (Setup user DOMAINsrvXXXSPSetup Member of the Local Administrators group on each server whereaccount) SharePoint is being installed. Member of the following SQL Server security roles: securityadmin fixed server role dbcreator fixed server role If Windows PowerShell cmdlets are used that affect a database, this account must be a member of the db_owner fixed database role for the database. This account is used to initiate the set up process on each server.SharePoint Farm Service Account DOMAINsrvXXXSPFarmSvc Configure and manage the server farm.(Server farm account or database Act as the application pool identity for the SharePoint Centralaccess account) Administration Web site. Run the Microsoft SharePoint Foundation Timer Service. Additional required machine level and database permissions are granted automatically to this account when SharePoint services are configured.SharePoint Service Applications and DOMAINsrvXXXSPServiceApps Account used to initiate service applications. This account is used byShared Service Applications Account application pools for specific Service applications.SharePoint User Profile and Properties DOMAINsrvXXXSPUPSSvc This account has been granted Active Directory delegation and replicateAccess Account changes rights required for the user profile synchronisation service.SharePoint Managed Metadata DOMAINsrvXXXSPMMSSvc The account used by the managed metadata service application pool.Account
  17. 17. Script the Provisioning and Configuration
  18. 18. Use of SQL AliasA SQL Server alias enables protection from SQL Server configurationchanges in a SharePoint farm It enables you to define a local alias name to connect to with a SQL Client Cliconfg.exe, SQL Server Client tools along with DNS are two methods for creating a SQL alias For Servers without SQL Server Client tools use Cliconfg.exeFollowing a SQL failure, or if you want to migrate to a different SQL Server,update the SQL Server Alias on each server to reference the new SQL Server
  19. 19. Use of DNS recordsUsed to reference “friendly” SharePoint Web Application URL’s DNS records created as an A record A records work better with Kerberos DNS records used in conjunction with Host Headers Friendly URL’s lend themselves to scaling out SharePoint FarmsDNS records created for all web applications•CA the exception unless external access required
  20. 20. Use of Port 80 & 443 for web applicationsSharePoint forms the basis of Web Applications Web applications belong on port 80 or 443 for future proofing Extending the web application out side the organisation > less reconfiguration when standard web ports are used Greater interoperability when communicating with BI and LOB applications Firewalls that block non standard web portsLoss of functionality and inaccessible links for extended sites
  21. 21. Kerberos vs NTLMNTLM is a lightweight and efficient protocol. Chatty Kerberos is industry standard protocol. Less Chatty Small SharePoint farm, simple AD domain with few servers in the farm, and SharePoint not required to authenticate with other applications, NTLM is a good choice. Large SharePoint farm or large number of users where SharePoint integrates with other applications like SSRS, Kerberos is a good choice. Kerberos solves double hop application domain authentication challenges.5 steps to implement. SPN creation, Server and User delegation, Web application configuration, test.• Fiddler 2
  22. 22. SQL Database maintenance Some of the ways you can optimize your database are • Defragmentation of the SharePoint databases • Defragmenting indexes – This is more beneficial to do indexes rather than tables for database performance • Shrink Database and log files Create maintenance plans • Check database integrity • Shrink Database Reorganize Index • Rebuild Index • Maintenance Clean-up task Un-supported Database operations •
  23. 23. Post Installation
  24. 24. Daily Tasks• Performing Physical Environmental Checks• Performing and Monitoring Backups• Checking Disk Usage• Checking the Event Viewer• Monitoring Server Performance• Monitoring Network Performance
  25. 25. Weekly Tasks• Archive Event Logs• Check for Security Updates• Review SLA Performance Figures• Archive Data• Environmental Tests• Database Maintenance
  26. 26. Monthly Tasks• Security Checks• Capacity Planning• Disaster Recovery Test
  27. 27. Key considerations on the impact ofSharePoint infrastructure
  28. 28. Type of SharePoint ImplementationConsiderations Type• No of users • Single Server Farm• Type of user • Multiple Server Farm• Target audiences • Multiple Farm Multiple Server• Structure of organisation • Dedicated Service Application• Type of access Farm• End user engagement • Development and Test Farms• Information Architecture • Fail over Farm• Existing supporting infrastructure• Performance and Redundancy• Cost
  29. 29. Users and type of user Read vs collaboration Light, End user Medium, adoption Heavy
  30. 30. Type of Access(Internal, External, Internet) Internal • URL • Authentication Model (Classic vs Claims, FBA, Integrated, NTLM vs Kerberos) External • URL, Zone, Internet HTTPS • Type of user • Access to • Type of site External Site • Target Audience
  31. 31. Physical Topology Changes• Architectural Components• Web Front End Server Changes• Application Server Changes• SQL Server Changes
  32. 32. Architectural Components• Architecture is familiar, many more design choices• No single point of failure• Web Front End Servers (WFE) – Some changes, mostly optimization• Application Servers – Many changes• MSSQL – Some changes and heavy optimization• 2010 is more flexible than 2007
  33. 33. Web Front End Server (WFE) Changes • New Hive Folder (14)• New client protocol (transports only deltas) • Throttling feature to better manage peak loads • New Usage Logging and • Client Health data synchronization changes
  34. 34. Application Server Changes• Many more services can run on an App Server• No More SSP (Upgraded it becomes the Search Service and Profile Service)• User Code Service is a separate isolated service that can run on one to many servers in the farm to isolate “sandbox” code• You can configure on a content db basis which server should be used to run timer jobs for that content db. You can also specify on which servers workflow timer jobs should run
  35. 35. MSSQL Server Changes• Many more databases to manage • Most service applications will have their own database • People service has 3, Search can have multiple crawl and property store databases• Snapshot management • You can force snapshots during backup • Content Deployment will support working off snapshots
  36. 36. MSSQL Server Changes cont...• Unattached content database restore • Browse through a content database that isn’t joined to a farm to find content to restore• Remote Blob Storage API • Replaces External Blob Storage (EBS) from SharePoint 2007 • Supports file stream providers for external storage
  37. 37. Typical NZ InfrastructureEnvironments
  38. 38. Typical NZ deployment scenarios StartWeb Front EndServers (WFE) • Dual/Quad Core Processors • 8GB for WFE (Virtualised) • 8GB for APP (Virtualised) • 8GB for SQL < Shared/Dedicated Application Servers (WFE) Suitable for typical medium size organisations in NZ (200-500 users) DatabaseBackend (Shared) • Collaboration sites (light) • Project Sites • Intranet
  39. 39. Typical NZ deployment scenariosWeb Front End GoodServers (WFE) • Dual/Quad Core Processors • 8GB for WFE (Virtualised) • 8GB for APP (Virtualised) Application • 16GB for SQL on a cluster or log Servers (WFE) shipping • Can support more than 1500+ users DatabaseBackend (Shared)
  40. 40. Large deployment scenarios NLB Best (Large high availability)Web Front End • Quad Core ProcessorsServers (WFE) • 8>12GB for WFE x 2 • 8>12GB for APP x 2 Application Servers (WFE) • 16>32GB for SQL on a cluster with log shipping/mirror • 10k users Database Backend (Dedicated)
  41. 41. References• SharePoint Server 2010 capacity management: software boundaries and limits 5733-448a-bd76-a8052b394fe2&displaylang=en• Capacity management and sizing for SharePoint Server 2010 404D-8853-57309F885722&displaylang=en• Topologies for SharePoint Server 2010 4F25-B65E-3CE7AA7DBEAB&displaylang=en• Services in SharePoint 2010 Products 43CA-A638-E1AD868187CE&displaylang=en• Plan browser support (SharePoint Server 2010)
  42. 42. Discussion
  43. 43. Thank you..• for any questions and feedback on today• Do you want to work with us?•
  44. 44. Thank you to our SponsorsMS COMMUNITIES