Designing SharePoint solutions – Big Decisions for Big Success


Published on

Speaker: Darko Milevski;

Today, many organizations use SharePoint as an ultimate platform for collaboration and consolidation of their business applications. At the same time, most of them find it easy for start-up implementation and almost plug-and-play use by employees. In time, the platform adopts more and more users, data, applications and processes, and if not architected and governed with this considerations, it becomes very tough to maintain and lose it’s performance and usability. Solid SharePoint solutions architecture at the beginning of implementation is crucial for long-term success, performance and usability of the applications on top of Microsoft prime enterprise content management platform. In this presentation, I will cover various aspects and considerations that should be analyzed and later implemented very carefully in a production SharePoint farm. Topics like Farm topology, SQL performance, Backups, Updates and Patching, Storage, Security and Governance will be covered. Form Development perspective, defining and negotiating Requirements, identifying constraints, policies, and selecting right SharePoint features and APIs that will be used in the solutions, is another aspect of the complete solution designing process.

Published in: Technology
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • We have to decide how many web front-ends we will installHow many Application ServersWhich Service Application we will use (do not run SA if not used, they use resources)Which SA will run on which Server, what about HA of some SADatabase Clustering and Mirroring
  • Almost everybody can install SharePoint
  • Web Parts can have propreties that can be changed by the Site Collection Administrators or event by usersSharePoint People Picker control is very powerful, not brandable, has error messages that will move your layoutManaged Metadata control – problem with adding new terms – need a hack
  • User Services to expose your functionalityAnemic-Domain Object Model
  • HTTP Request to read Config settings – often and slowConfiguration caching -> cons require IISRESETXML – XSLT technique – easy changeableCustom localization -> user/admin can change localizations
  • Designing SharePoint solutions – Big Decisions for Big Success

    1. 1. Designing SharePoint solutionsBig Decisions for Big SuccessDARKO MILEVSKI, NEXTSENSESHAREPOINT AND PROJECT CONFERENCE ADRIATICSZAGREB, 11/28/2012
    2. 2. sponsors
    3. 3. Breaking the “knows everything”stereotype• SharePoint (…, 2010, 2013,…) has become a truly massive platform that can be thought of as an operating system for Information Workers.• In this context, it is becoming increasingly difficult for any single individual to know everything about SharePoint.• Instead, the community of SharePoint professionals is specializing. Some of us are workflow experts, others are web content management experts, still others are focused on data integration.• Furthermore, it is now impossible to collect all of the end user, administration, and development knowledge for SharePoint into a single resource.
    4. 4. PollInfrastructure Development• SharePoint Farm • SP Web Pages & Web Parts• Web-Front end server • Web Services & WCF• Application Server • SharePoint Object Model• SP Service Applications • Scripting (JavaScript, jQuery)• SharePoint Web Application • Configuration• Configuration & Content • Logging Databases • Notification• Site Collection
    5. 5. Agenda• Designing SharePoint Farm• Installing SharePoint Farm• Maintaining SharePoint Farm• Planning SharePoint Solutions• Developing SharePoint Solutions• Deploying SharePoint Solutions
    6. 6. SharePoint Farm ServersA SharePoint farm is a collection of SharePoint servers (and SQL Servers) thatwork in concert to provide a set of basic SharePoint services that support asingle site.
    7. 7. Limited deployments (1-2 servers) SharePoint Farm TopologiesLimited deployments are typically used for product evaluation,development and testing, or for environments that have limitednumbers of users and don t require fault-tolerance.One-server farm Two-tier farm Three-server virtualized farmEvaluation or <100 users Up to 10,000 users Use virtualization to maximize the potential of a smaller number of servers All roles on one server, All Web and application Two web servers are predicted to serve including SQL Server server roles 10,000-20,000 users. Host A Host B Databases Web server Web server All application All application server roles server roles All SharePoint databases
    8. 8. SharePoint Farm Topologies Smallest fault-tolerant farm utilizing Six-server virtualized farm virtualization Host A Host B All farm server roles virtualized and distributed across two or four host servers (depending on the operating system) to provide fault tolerance using Web server Web server the minimum number of servers. Windows Server 2008 R2 Web server Dedicated Host A Host B Web server for crawling Host C Host D Web server Web server All application All application Query and Query and index index server roles server roles All other All other application application Host C server roles server roles Host D Host E Host F All All databases databases All All databases databases SQL Server installed and configured to support SQL clustering, mirroring, or AlwaysOn. AlwaysOn requires SQL Server 2012. SQL Server installed and configured to support SQL clustering, mirroring, or AlwaysOn across both of the hosts. AlwaysOn requires SQL Server 2012.
    9. 9. Multiple SharePoint Farmstrough product lifecycle
    10. 10. Installing SharePoint Farm• Next -> Next -> Finish experience• Everybody can install SharePoint Server?• Installing SP2010 SP1 (Patches)• Install, Update than Configure• Configuration Wizard vs. PowerShell • Control all accounts (Least Privileged Accounts installation) • Control Service Applications (which will be installed) • Control Database names
    11. 11. Database names problem
    12. 12. SQL Database considerations (1)• Database/Storage Configuration • Recommended database file placement priority (fastest to slowest drive) • tempdb data and t-log files • Db transaction log files • Search db data files • Content db data files • Place tempdb, Content and t-logs on separate LUNs • Use multiple data files for big Content and Search dbs • Distribute equal-sized data files across separate disks • # of data files should be <= # of processor cores • Multiple data files are not supported for other dbs
    13. 13. SQL Database considerations (2)• Database/Storage Sizing • Limit Content DBs to 100 GB (soft limit) • MS Supported 200GB – General Usage • MS Supported 4TB – 0.25 IOPs per GB + 2 IIOPs per GB • You will easily upgrade • Size SQL Server data files appropriately • Pre-allocate data file to cover anticipated size of Content db • Set SQL „Autogrow‟ to fixed value appropriate for size of db • Do not over-autogrow • Use dedicated database for large Site Collections (> 50GB) • Better: > 20GB
    14. 14. Maintaining SharePoint Farm• Service Level Agreement• Availability• Maintenance windows• Backups • SharePoint Backups • PowerShell • 3rd Party tools • SQL database backups• ULS Logs
    15. 15. SQL Databases Maintenance• Monitor SQL Server performance regularly• Defragment physical files• Content and Search dbs most susceptible• Rebuild / Reorganize indexes to eliminate fragmentation • Reorganize index when fragmentation between 10-70% • Rebuild index when fragmentation > 70%
    16. 16. Planning SharePoint Solutions• Gathering requirements• Map requirements to features• Carefully consider constraints • Max content size db • Max items per list / max sub-sites, etc. • One content db per site collection• Prototyping is not enough • Most of the “Hello world” blogs are not completely true• Pessimistic SP Logical architecture
    17. 17. SharePoint Solution Design DAL Interfaces (SQL and SP) ADO SP OM .NET
    18. 18. Front-end Development• Which Pages to use? • Application pages (_layouts) • Web Part Pages (db)• Custom Web Parts vs Custom Forms • SharePoint Web Controls (pros – cons)• UI development – Client Side Scripting • JavaScript • jQuery • Knockouts• Async• Branding: Custom master and CSS
    19. 19. Back-End Development• Middle Service Layer • Avoid implementing logic• Back-end Business Layer • Entity Classes • Business Logic Services (Adapters/Providers) • Patterns vs Anti-Patterns• Dependency Injection – data store version independent• Data stores: SharePoint and SQL• Implement Interface, reference current SP Versions
    20. 20. Common (Back-end) Development• Config (Storing Configuration values) • SharePoint List vs Application Settings (web.config) • Configurator caching• Logging • Log in file (log4net) • ULS (UlsViewer)• Massaging • Common mailing system • Use SharePoint configured SMTP • Data -> XML -> XSLT -> HTML body• Localization • Features Localization -> Resource files • Solution Localizations -> Resource files vs Custom
    21. 21. Data-Layer Development• Many Items -> use SQL database• Consider SharePoint List query performance• Avoid frequently used complex CAML queries• Organize (structure) sites, sub-sites and Document Libraries• Distribute files across many site collections if total size exceeds 100GB• Always consider performance in SP code
    22. 22. Deploying SharePoint Solutions• PowerShell – ultimate tool for SP manipulation • Install • Upgrade • Backup• Write ps scripts for installation process automation • Mix SP, shell, SQL and other commands • Recreate your development site collections • Deactivate-Activate Features (redeploy) • Recreate your Content Types, Terms, Reindex, etc.