2. A Little Background Troy Lanphier Background in Server and Storage Infrastructure SharePoint Technical Focus since 2003 Microsoft Certified Trainer Over 15 years of consulting experience Technical Editor – O’Reilly/MS Press
3. 10 Tips for Creating a Flexible SharePoint Implementation Tip 1: Don’t Default!
4. 10 Tips for Creating a Flexible SharePoint Implementation Tip 1: Don’t Default! Part One – Use Named Instances
5. Tip 1 – Use SQL Instances A Named Instance is simply a way to partition one set of SQL databases from another on the same server, allowing them to function independently of one another. Should all databases live in the same instance? How is maintenance handled? What about security and service accounts? SQL Collation for SharePoint Databases - Latin1_General_CI_AS_KS_WS The Problem Shared SQL Server Instance
6. Tip 1 – Use SQL Instances Should all databases live in the same instance? How is maintenance handled? What about security and service accounts? Instance is referred to by “servername/instance” Each Named Instance is segregated – more secure Maintenance is performed on each Instance Licensing costs are reduced Consolidations have less effect on SP Operations The Problem The Solution Shared SQL Server Instance Create a Named Instance
7. 10 Tips for Creating a Flexible SharePoint Implementation Tip 2: Don’t Default!
8. 10 Tips for Creating a Flexible SharePoint Implementation Tip 2: Don’t Default! Part Two – Content and SA DBs
9. Tip 2 – Watch out for the Wizard If you run the Wizard to build your service applications in SP2010, you get an appended GUID. If you build Content Databases, name them appropriately to avoid a GUID GUIDs make it difficult to administer DBs Scripts, in particular do not like the “-” Some Third Party tools will not work with databases that contain GUIDs in the name The Problem GUIDs
10. Tip 2 – Watch out for the Wizard GUIDs make it difficult to administer DBs Scripts, in particular do not like the “-” Some Third Party tools will not work with databases that contain GUIDs in the name GUID – Globally Unique IDentifier When building Content Databases, never use the “WSS_Content” default The next “automatic” name will have a GUID Build Service Applications Manually or via Script Specify the Database names The Problem The Solution GUIDs No GUIDs
11. 10 Tips for Creating a Flexible SharePoint Implementation Tip 3: Use an Alias
12. 10 Tips for Creating a Flexible SharePoint Implementation Tip 3: Use an Alias, Become more flexible
13. Tip 3 – Alias your SQL Instance A SQL Alias is used to create a “database server name” that actually refers to your SQL Named Instance, e.g. “SPSQL” instead of “servernamenstance”. What happens when the database server is decommissioned? Changing SQL Database servers is possible for a SharePoint farm, but there are better ways to spend your weekend The Problem Using just the Instance Name
14. Tip 3 – Alias your SQL Instance What happens when the database server is decommissioned? Changing SQL Database servers is possible for a SharePoint farm, but there are better ways to spend your weekend Build an Alias on each farm server using cliconfg The Alias is used in setup instead of directly referring to the instance name Gives you an easy way to back out of a failed database server move The Problem The Solution Using just the Instance Name Create a SQL Alias on the Farm Servers
15. 10 Tips for Creating a Flexible SharePoint Implementation Tip 4: Service Level Agreements
16. 10 Tips for Creating a Flexible SharePoint Implementation Tip 4: Service Level Agreements - Not as bad as you think
17. Tip 4 – Service Level Agreements A Service Level Agreement defines the levels and requirements for expected (and sometimes unexpected) farm outages Some portions of the business may see SharePoint as a critical service Any outage may be perceived as an unexpected outage All events are created equal The Problem No Service Level Agreements
18. Tip 4 – Service Level Agreements Some portions of the business may see SharePoint as a critical service Any outage may be perceived as an unexpected outage All events are created equal Create an understanding between the Business and IT about what constitutes services availability. Define different processes for Outages, Business Continuity, and Flat-Earth (DR) Events One size may not fit all The Problem The Solution No Service Level Agreements Create a Resilient SLA
19. 10 Tips for Creating a Flexible SharePoint Implementation Tip 5: Sites vs. Site Collections
20. 10 Tips for Creating a Flexible SharePoint Implementation Tip 5: Sites vs. Site Collections - Segmenting the Data
21. Tip 5 – Sites vs. Site Collections In most out of the box installations, only a handful of Site Collections are utilized; each contains a series of Sites. Collaborative and Publishing sites are intermingled As the site grows and subsites are added, navigation becomes an issue No logical way to separate data The Problem Using Few Site Collections
22. Tip 5 – Sites vs. Site Collections Collaborative and Publishing sites are intermingled As the site grows and subsites are added, navigation becomes an issue No logical way to separate data Allows data to be segmented, fostering scalability Gives business the ability to self-manage collaborative sites Partitions collaborative and publishing sites Managed Paths allow SCs to be nested The Problem The Solution Using Few Site Collections Use Multiple Site Collections
23. 10 Tips for Creating a Flexible SharePoint Implementation Tip 6: Define Managed Paths
24. 10 Tips for Creating a Flexible SharePoint Implementation Tip 6: Define Managed Paths - Smooth Navigation
25. Tip 6 – Define Managed Paths Multiple Site Collections can be placed in the same Navigational Hierarchy. Without Managed Paths, each Site Collection requires a distinct URL Users navigating the site can become confused by an ever-changing URL structure The Problem No Managed Paths
26. Tip 6 – Define Managed Paths Without Managed Paths, each Site Collection requires a distinct URL Users navigating the site can become confused by an ever-changing URL structure Allows for Site Collections to be nested Example – http://portal /sitecollection Wildcard Managed Paths also exist Example – http://portal/EMP/sitecollection The Problem The Solution No Managed Paths Use Explicit Managed Paths
27. 10 Tips for Creating a Flexible SharePoint Implementation Tip 7: Use Quotas Effectively
28. 10 Tips for Creating a Flexible SharePoint Implementation Tip 7: Use Quotas Effectively - It’s easier to give than take
29. Tip 7 – Use Quotas Effectively Quotas are assigned at a Site Collection Level; when a site nears its maximum capacity, the Primary and Secondary Site Collection Owners are notified. No maximum storage = unbridled growth If a Site Collection requires more space, then a different quota can be applied When the Site Collection is big enough, it can be moved into its own Content DB The Problem No Quotas or Quota Templates
30. Tip 7 – Use Quotas Effectively No maximum storage = unbridled growth If a Site Collection requires more space, then a different quota can be applied When the Site Collection is big enough, it can be moved into its own Content DB Initially define a core set of quotas Decide early on what the process is for sites nearing their max size Determine if the different quotas rate different treatment in the Service Level Agreement The Problem The Solution No Quotas or Quota Templates Build and Apply Quota Templates
31. 10 Tips for Creating a Flexible SharePoint Implementation Tip 8: Spread the Wealth
32. 10 Tips for Creating a Flexible SharePoint Implementation Tip 8: Spread the Wealth - Don’t Skimp on the DBs
33. Tip 8 – Use More Than One DB Content DBs can host thousands of Site Collections. If multiple Content Databases are assigned to a Web Application, SharePoint will build SCs in “Round Robin” fashion, filling the DBs fairly evenly. An “Out-Of-The-Box” experience will build one Content DB per Web App. Storage Capacity becomes an issue Data Recovery becomes an issue The Problem Using One Content DB
34. Tip 8 – Use More Than One DB An “Out-Of-The-Box” experience will build one Content DB per Web App. Storage Capacity becomes an issue Data Recovery becomes an issue A single Web Application can have multiple Content Databases Build and Lock your Publishing Site Content DBs Build Multiple Content DBs for Collaboration The Problem The Solution Using One Content DB Create Multiple Content DBs
35. 10 Tips for Creating a Flexible SharePoint Implementation Tip 9: Cooking in the Kitchen
36. 10 Tips for Creating a Flexible SharePoint Implementation Tip 9: Cooking in the Kitchen - Eating in the Dining Room
37. Tip 9 – Cooking in the Kitchen Using Site Collections, Quotas and Managed Paths, you can begin to think about segmenting Collaborative and Publishing site functionality. Not all info should be shown to everyone Permissions can become problematic Discarded Sites are not apparent No automated monitoring of site use The Problem Generating and Consuming Data in One SharePoint Site
38. Tip 9 – Cooking in the Kitchen Not all info should be shown to everyone Permissions can become problematic Discarded Sites are not apparent No automated monitoring of site use Collaborative sites may not require stringent controls Sites can be built that cross business divisions Discarded sites are monitored automatically A process to retire unused SCs must be in place The Problem The Solution Generating and Consuming Data in One SharePoint Site Create Non-Publishing Sites as Separate Site Collections
39. 10 Tips for Creating a Flexible SharePoint Implementation Tip 10: One to One Collaboration
40. 10 Tips for Creating a Flexible SharePoint Implementation Tip 10: One to One Collaboration - Enabling Personal Sites
41.
42. Tip 10 – Use More Than One DB My Sites are often not used Perceived lack of governance My Sites are often not planned A lack of databases equates to large DB(s) Populate the “Manager” field Decide how sites should be “retired” Site Quotas should be applied for the “My Sites” Web Application The Problem The Solution My Sites: Not used or not planned Create Multiple Content DBs