SharePoint Preparedness: By Failing to Prepare, You Are Preparing to Fail

1. SharePoint Preparedness:By Failing to Prepare, You Are Preparing to Fail Danny Jessee | Protiviti | June 14, 2013

2. Who Am I? SharePointArchitect Washington, DC metro area 9 years SharePoint experience danny.jessee@protiviti.com MCPD, MCTS SharePoint Developer 2010 SharePoint 2010, Configuring @dannyjessee

3. Agenda • #SharePointHorrorStories • What is Preparedness? • Pre-Deployment Preparedness • Hardware and Architecture Preparedness • Authentication and Authorization Preparedness • Content and Metadata Preparedness • Disaster Recovery Preparedness • Reigning in the Chaos

4. How many of you are… • Developers? • System administrators? • IT professionals? • Business users? • What version(s) of SharePoint are you supporting? • You all have unique “SharePoint Preparedness” responsibilities

5. #SharePointHorrorStories • Everyone seems to have one… • What’s yours? • What do all these stories have in common?

6. What is Preparedness? • Preparedness (pri-ˈper-əd-nəs) n. – the quality or state of being prepared; especially: a state of adequate preparation in case of war • Are you at war with SharePoint? Why? • “To defeat the enemy, you must first understand the enemy” • Know and understand your options and who can help you achieve your objectives!

7. SharePoint Preparedness

8. Pre-Deployment Preparedness “What hardware and software do we need? Who is actually going to use this thing?”

9. Hardware & Architecture Preparedness • Hardware/software requirements • Upgrading from an older version? Migrating from something else? • Small/medium/large farm • Physical/virtual • On-premises/cloud • Development/integration/staging environments

10. Hardware & Architecture Preparedness • How many servers will you need? • Physical or virtual? Or cloud? • Topology: single-tier/two-tier/three-tier • Size: small (2+1)/medium (2+2+1)/large • Can be based on numbers of users ordocuments • Web/application/database servers • Availability requirements? SLAs?

11. Authentication Preparedness • How will your users log in? • Windows • Your company’s Active Directory domain • Forms-based • Custom identity store, AMS, etc. (ASP.NET membership/role providers) • Custom trusted identity provider • Public facing sites: OpenID (Facebook, Google, Yahoo, Windows Live) • Classic vs. Claims

12. DEMO Configuring authentication providers

13. Authorization Preparedness • SharePoint groups/AD groups • Best practice: assign permissions only to SharePoint groups • Add individual users and AD groups to SharePoint groups • Define these groups before sprawl (site and permissions) takes over • Anonymous access? • Requires action in central administration and the individual site • Breaking inheritance/item-level permissions • Resist the temptation!

14. Content and Metadata Preparedness “Taxonomy? Doesn’t the IRS handle that?”

15. Content and Metadata Preparedness • What kind(s) of content will you be storing in SharePoint? • How will users discover and consume content? • Evaluate what SharePoint provides out-of-the-box

16. Content Type Publishing • Allows you to define content types in one site that can be shared/published across site collection and web application boundaries (even across farms!) • Controlled by timer jobs that run on each “content type subscriber” web application • Requires a Managed Metadata Service Application • Managed metadata • Group  Term Set  Term

17. DEMO Sharing content types across web applications!

18. Search and Discovery Preparedness • Content sources • Crawl schedules • Keywords, synonyms, and best bets • Metadata navigation

19. DEMO Search settings, managed metadata, and metadata navigation

20. Disaster Recovery Preparedness “The flood took out the server hosting our backups. Fortunately, the production server survived.”

21. Disaster Recovery Preparedness • A disaster does not necessarilyhave to mean a hardware failure! • But you should plan for those, too • Monitor things like: • Health analyzer errors/warnings • Site collection storage quotas • Available disk space on DB server • Are your backups actuallysucceeding? Test them!

22. Disaster Recovery Preparedness • Sometimes “disasters” can comefrom within • Developers release untested code • SharePoint Designer has beenknown to cause a problem or two… • Thoroughly research and test“solutions” to problems before going to production • Resist directly querying/updating the SharePoint databases at all costs!

23. Disaster Recovery Preparedness • Determine your RPO, RTO, and RLO • Recovery Point Objective – how far back? • Recovery Time Objective – how long to restore? • Recovery Level Objective – how granular the content? • Tradeoffs and associated costs • When choosing a backup solution, consider: • Speed of backups, resource requirements, granularity of backups • It’s all (largely) about the databases!

24. The “G” word “Ain’tnuthin’ but a G[overnance] thang”

25. Governance • Governance is the set of policies, roles, responsibilities, and processes that guide, direct, and control how an organization’s business divisions and IT teams cooperate to achieve business goals • Good governance is essential to a successful SharePoint deployment

26. Governance • A SharePoint governance plan shouldaddress: • Information architecture • IT service • Branding and customizations • Training • “It takes a village” • Don’t make writing the governance planan assignment for one person! • Resist the temptation to rely (too heavily) on a template

27. Reigning in the Chaos “Calgon…take me away!”

28. Chaos: patching and updates • Not like updating iPhone apps • Requires preparation! • Don’t just install blindly • Test in a non-productionenvironment first • Make sure your test environment mirrors your production environmentto the greatest extent possible • Do not deploy a Cumulative Update unless it addresses a specific problem you are experiencing

29. Chaos: managing custom solutions • If you are deploying custom code/solutions from your developers,make sure they are packaged assolution (.wsp) files! • Ensure custom code is thoroughlytested in an integration environment first • If a developer ever wants to copy files or manually alter system configurations on a production server, hit the button!

30. Chaos: list columns, choice fields • It is almost too simple for end users to add columns directly to lists • These are list columns and not site columns • Zero reuse potential • Cannot “convert” a list column to a site column • If you intend to use a column in more than one place, strongly consider building out the appropriate hierarchy • Site columns  Content types  Publish the content type for reuse

31. Reigning in the chaos • Invest in separate development/integration/staging infrastructure, especially if custom solutions are being developed/deployed • Thoroughly test custom code/in-house/third party solutions – don’t test in production! • Evaluate patches and updates, ensure CUs address an issue you have • Before you create a list column, ask yourself: • Will I ever need to use this column in another list? • Should this be a “Choice” field or should I use managed metadata?

32. What does this all mean? • You can’t do it alone! • Requires support from: • C-level staff • IT staff • Developers • End users • Family • Friends • Pets • Your local SharePoint user group

33. Continuing Preparedness • Remain vigilant! • Know the right places to look for help • Continually seek input from key stakeholders and users • Be quick and responsive, proactively solve major issues • Focus on the end user experience

34. Questions? “Don’t worry; we’ve all been there.”

35. Thanks for your time! @dannyjessee dannyjessee.com/blog danny.jessee@protiviti.com