Building a SharePoint Platform that ScalesPresentation Transcript
WELCOMEBuilding A SharePoint SharePoint Saturday Dayton Dayton, Ohio 6/30/2012Platform That ScalesScott Hoag and Dan Usher
Who are we?Scott Hoag• Infrastructure Consultant at Applied Information Sciences• Jack of All Trades, Master of Some• With over 8 years of experience, Scott has been utilizing Microsoft based content management solutions from MCMS 2002 to SharePoint 2010 today• Enjoys discussions about user adoption, search, and world peace• Twitter: @ciphertxt
Who are we?Dan Usher• SharePoint Engineer at Booz Allen Hamilton• 7 years of experience with SharePoint going back to adventures with STS 2001 and SPS 2003 to the present…• Enjoys discussions about Claims AuthZ, SmartCard AuthN, Atomic Molecular Optics & the Walking Dead• Follows the SharePoint Credo - ADIDAS All Day I Dream About SharePoint• Twitter: @usher
Monologue• Determine your business case• Determine your scope• Determine your metrics and success criteria• Determine your boundaries
What could go wrong?• Logical Architectures skipped…• Site Collections gone viral…• Site Permissions are confusing…• Where’d my admin access go….• Information can’t be found…• Search isn’t working right…• System seems to be dragging…Was this system intended for users?
System Visioning…Content Management Enterprise SearchCollaboration Business ProcessesPortals FindabilityExtranets Business Intelligence Workflow Process Reporting Forms Dashboards
What’s a vision look like?• Business Goals – What’s the context of your use for SharePoint? – What are you trying to accomplish with SharePoint?• Business Structure – Do you have a defined organizational hierarchy? – Do you know your key organizational processes?• System Functionality – Do you need to be able to aggregate and roll up data to dashboards?
Vision components (cont’d)• System Functional (con’t) – Are Workflow or Business Process Management tools a need? – Are forms and their lifecycles important to you? – Integrations and interoperability with external systems• SharePoint as a Service – Small order of document library – Large order of Business Intelligence and Excel Services – Medium order of collaboration
Stepping into Contextual Thinking…• Considerations, Tradeoffs and Compromises to meet the Context• Assessing the context……every situation has its circumstances
Do you feel like it’s like this?
Logical Architecture and Users• Defines the underlying information lifecycle management framework• Impacts usability of information and experience• Defines process flow
Logical Architecture• What defines a logical architecture?• Why is a logical architecture important?• How can you really make use of a logical architecture?• What does a logical architecture consist of and look like?
What technically makes up a logical architecture? • Web Zones (Intranet,• Web Applications Extranet, Internet, – Service Apps etc.) and Policies – Subscription Groups • Different – My Sites Authentication – Team Sites Models – Publishing Sites • Content Databases • Site Collections • Application Pools
SharePoint 2010 Corporate Intranet Example Reference: http://j.mp/MSfHCL
Topologies for SharePoint 2010Reference: http://j.mp/MSg9B6
How is your logical architecture affected by your requirements? • Extranet / Public Facing Website • Permissions models • Authentication Schemes • Interoperability with other applications – Office Client, WPF, WCF, BCS, Silverlight… • How you anticipate your users interacting with your platform
What is a taxonomy?• Taxonomy is the science (and art) of classifying a broad range of things. Originally used to classify plants and animals – phylum, genus, species, etc. – taxonomy is now applied to everything from product inventory to web sites. Reference: http://bit.ly/sps-ref-tax
SharePoint’s Site Taxonomy• SharePoint Farms – Nesting Paths / Excluding Paths• Reflection of the Organization• Requires out of the box thinking• Federated Search• Shared Services across Farms• Multitenancy
SharePoint’s Site Taxonomy Farm Web Application Web Application Site Site Collection Site Collection CollectionSite Site Site Site Site Site Site Site Site
What’s that look like? SharePoint Monkey (Farm) sharepointmonkey.org (Web App) Work Sites Root Site (SC) (Excluded Path) / /work/ Personal Sites Blog (Site) Search Center (Site) Development (SC) SharePoint (SC) Networking (SC) (Excluded Path) /blog /search /work/development /work/sharepoint /work/networking /personal Program ManagementDan’s MySite (SC) Laura’s MySite (SC) Todd’s MySite (SC) (Site) /personal/dan /personal/laura /personal/todd /work/sharepoint/pm
But do I really need a taxonomy?• Why not just deposit everything in a single document library?• Won’t document sets solve that problem?• Search will solve all my problems… – What document is authoritative? – The document isn’t surfaced…• End User Impact
Taxonomy Limitations• Cross Site Collection Navigation – 2007 Solution - CodeProject.com – Shared Navigation Provider – 2010 Solution - Roll your own solution… • Content Types & Site Columns – Managed Metadata Service – Content Hubs and number of associations• Workflows• SharePoint Security Groups and Scopes available through a Site Collection
What about permissions?• Well it depends on the site taxonomy…• Inheritance and Breaking it… – …and re-inheriting it• Web Application Policy – Overriding all your other policies…• Defined in a Governance Plan hopefully? – SharePoint Groups – AD / LDAP Groups – Single Users – Claims
Taxonomy & Logical Architecture – What’s the Bridge?• Site collections and their web applications – Site Collections root container for sites – Web Applications tied to content databases and infrastructure• The design goals for site collections in the model are to satisfy requirements for URL design and to create logical divisions of content.*Reference: http://bit.ly/sps-ref-sc
Is there a secret to success? Gather Complete Stakeholder Planning for Determine Prototype Validate User Implement Functional Information and Design Micro- Acceptance of Macro- and Process Flow and Taxonomy Taxonomy Taxonomy TaxonomyRequirements Aggregation
Project Plans• How does a project plan fit into logical architectures and taxonomies?• Or rather…• How does a logical architecture and taxonomy fit into a project plan…
Project Plans• Microsoft has a project plan for planning… http://go.spdan.com/hmewo
Course Corrections…• Never too late to pin down a way ahead• SharePoint’s flexibility provides for change – Third party management and migration tools – SharePoint Admin Toolkit – Using the tools that are a part of the platform (Features/Web Parts/WSPs)• Migrate to a clean environment – Utilize a proxy for access
Technical Requirement Considerations• What’s the vision again? What will the platform provide for? – Heavy Collaboration? – WCM Publishing? – Workflow Application Development Platform?• How much content will there be?• How will it be accessed?• What will be the level of usage?• Are we dealing with a cross domain solution?• Do we have SLAs to meet?
What are your limitations technically?• Surrounding Infrastructure – AD – Network Capacity – Boundaries• Offline Capability• System Memory• IIS – Number of Web Applications – Number of Identity Pools• Number of sites / site collections
Technical limitations (cont’d)• DNS• Authentication Methods• PKI / SSL / Wildcard Certificates• Network Interfaces / IP Addresses• StorageIt all ends up impacting the end user experience…
Recovery Limitations High Availability and Disaster Potential Potential Automatic Readable Recovery Data Loss Recovery Failover Secondaries (RPO) Time (RTO) SQL Server Solution AlwaysOn Availability Group - synchronous- Zero Seconds Yes 0-2 commit AlwaysOn Availability Group - asynchronous- Seconds Minutes No 0-4 commit AlwaysOn Failover Cluster Instance NA Seconds Yes NA -to-minutes Database Mirroring - High-safety (sync + witness) Zero Seconds Yes NA Database Mirroring - High-performance (async) Seconds Minutes No NA Log Shipping Minutes Minutes No Not during -to-hours a restore Backup, Copy, Restore Hours Hours No Not during -to-days a restoreSource: Michael T. Noel - http://slidesha.re/MIjJM7
Conclusion I• Each SharePoint implementation project requires that you examine the contextual considerations of the environment and define a vision.• Defining such a vision will provide goals to work toward, to make your implementation both successful and effective to end users.
Conclusion II• Your requirements drive your taxonomy and logical architecture...• Which in turn drive your hardware requirements...• If you dont know what youre going to use SharePoint for, start off small and scale your farm up as you go...• Crawl… Walk… Run…
Conclusion III• What you start with on Day One isn’t what you’re going to end up with in… – Six months… – A year… – Day 472… Remain Flexible!!!
Conclusion IVUser adoption in and of itself will cause your environment to change……adapt to the context as it changes.
Come Read Our Blogs!It’s all true… really… • Follow us… http://psconfig.com – twitter.com/ciphertxthttp://www.spdan.com – twitter.com/usher
SharePoint Saturday Dayton has been made possible because of generous sponsorship from the following friends…
What’s a good reference?• Planning for Software Boundaries – Software Boundaries and Limits - http://technet.microsoft.com/en- us/library/cc262787.aspx – Capacity Management and Sizing - http://technet.microsoft.com/en- us/library/cc261700