Inside the mind of a SharePoint Solutions Architect

Transcription

1 Inside the mind of a SharePoint Solutions Architect Noorez 23 mai 2015

2 Bronze Web Or Argent Merci à nos commanditaires!

3 Speaker Bio Noorez Khamis aka Rez SharePoint Architect Microsoft MVP About me: blog: Rez s SharePoint Blog Spot - SharePoint Solutions Architect (currently at Toyota Canada) 14+ years in managing, leading, designing and implementing SharePoint business solutions across a wide variety of verticals Involved in hundreds of projects spanning entire SharePoint spectrum including enterprise scale document and records management systems Active blogger and involved in GTA SharePoint community MBA, MCTS, MCDBA, MCSD, MVP

4 So what s this session about anyways? Provide some insight and tips on what to consider when designing and architecting your SharePoint solution Target Audiences: IT Professional SharePoint Administrator Aspiring SharePoint Architect/Developer Lots to cover so let s keep the questions at the end

5 Key takeaways There are many right ways to optimally design and architect a solution but there are more ways to do it wrong so up front planning is critical Technical design and architecture should be driven by the project requirements as well as by the schedule and budget constraints at hand Business drives technology, let s not forget why we are here. Blogs, TechNet and MSDN do not always have the solution that is right for you so try and get a broad understanding of capabilities Ensure an appropriate amount of security planning for all of your projects

6 Agenda Essentials for any SharePoint Consultant Architectural Changes in SharePoint 2016 Planning your deployment Some tips from the following standpoints: Infrastructure Performance Security Logical Architecture Maintenance Add-ons

7

8 Understand the breadth of SharePoint SharePoint stack is a HUGE set of individual technology features under the SharePoint Platform umbrella Involves time, patience, testing and mistakes Requires years of experience in the field to be considered an expert and it virtually is impossible to be an expert at every aspect in SharePoint especially with it changing every month SharePoint veterans still learn something new every day Understand that there is no one right way to accomplish your objectives However, as a SharePoint Architect, it is important to be aware that these features exist and at least a high level understanding of each

9 Experience and practice SharePoint based implementations/projects/hands-on experience more valuable than someone who excels at exams/certs/theory Certifications are good but ensure practice of the knowledge gained Concentrate on a specific SharePoint niche and let it become your strong point Experienced people are 2-3 times more efficient and their up front costs/wages/salaries may be more but cost savings for the company in long run and more successful projects with greater adoption Know when to use OOTB vs. Custom Components

10 Know your users User Experience is very key to designing and architecting a SharePoint solution How will they use the system you are building? What do they want to accomplish? Is what you are building over complicated? Does it meet and exceed the business requirements from the user persp? Have you tried to use it from their stand point? Is it an intuitive interaction? What are their pain points? Have you developed card sorts and wireframes to test out and understand what you are building for the user? Leads to Adoption and hence successful projects!

11 Communication skills are necessary Communication is the cornerstone for any SharePoint consultant With SharePoint, majority of roles (even developers) need to know how to deal with business and end users, they are not just locked up in a room Ability to understand, empathize and discuss the business needs with your users and colleagues Converse and connect with people on the business problems and alternate ways on how to solve them Face to face, rather than helps build this skillset Lots of resources around to help with this (Toastmasters, community and college courses, etc )

12 Know yourself Where is your Niche? What do you love doing? BI, WCM, DM, RM, Social, ECM, Search You don t have to be an Enterprise Architect to be a SharePoint Architect A SharePoint Architect most of the time is not just that IT Pro, Infrastructure Specialist, Dev Lead, Business Liaison There is no Jack of all SharePoint Trades Try to learn and become as well rounded in SharePoint technologies as possible but become great at one aspect Inevitably leads to you learning and understanding many SharePoint aspects Clearly understand, experience and be able to articulate that one aspect

13

14 Looks like small changes at first glance Very similar as SharePoint 2016 in terms of infrastructure More powerful hardware needed! Microsoft aspiring to have enterprises have hybrid SharePoint environments New MinRole installations and provisioning with SP Health Analyzer Scanning to ensure MinRoles WebFrontEnd Application Specialized Load DistributedCache Patching Smaller update footprint Reduced number of MSI and MSP In-place, online, installation User Profile Service separate server Durable Links - Url remains intact with rename and move across site collections

15 Hardware Requirements Memory Processor Disk Single Server Foundation (Integrated or Standalone Database) SP 2013: 8 GB SP 2016:? SP 2013: x64 1x4 cores SP 2016:? SP 2013: 80 GB (OS) SP 2016:? Single Server (Integrated or Standalone Database) SP 2013: 10 GB*, 24 GB SP 2013: x64 1x4 cores SP 2013: 80 GB (OS) *Development Environment/Evaluation SP 2016: GB SP 2016: x64 1x4 cores SP 2016: 80 GB (OS) *Min services for Dev Web / Application Servers SP 2013: 12 GB SP 2013: x64 1x4 cores SP 2013: 80 GB (OS) *Pilot, Production, Servers in a Farm SP 2016: GB SP 2016: x64 1x4 cores SP 2013: 80 GB (OS) Want a full list? Go to my blog post:

16 Prerequisites Prerequisites Windows Management Framework 3.0 Application Server Role Web Server (IIS) Role Microsoft.NET Framework Update for the.net Framework 4 (KB ) Microsoft SQL Server 2012 Native Client Microsoft Identity Extensions Microsoft Sync Framework Runtime v1.0 SP1 (x64) Windows Server AppFabric 1.1 Windows Identity Foundation v1.1 Microsoft Information Protection and Control Client Microsoft WCF Data Services 64-bit edition of SQL Server 201x 64-bit edition of Microsoft SQL Server 2014 Service Pack 1

17 Deployment Requirements SharePoint 2010 SharePoint 2013 SharePoint 2016 Workgroup Supported Unsupported Unsupported Domain Controller Supported for SBS Only for Developer Installation Only for Developer Installation Client OS Developer Installation Unsupported Unsupported Dynamic Memory in VMs Windows Web Server Unsupported Unsupported Unsupported Supported Unsupported Unsupported Source: SPC 2012

18 Boundaries and limits in SP 2016 Content Database Size Site Collections per Content Database List Threshold MaxFile Size Indexed Items Content database sizing into TB s 100,000 site collections per content database Increased List Threshold >5000 MaxFile Size increases to 10GB and removed character restrictions 2x increase in Search scale to 500 million items

19 Upgrade & Migration to SP 2016 Upgrade Migration Upgrade 14.5 mode site collections to 15 mode Attach SharePoint 2013 databases to SharePoint 2016 Migrate content to SharePoint 2016

20

21 Understand your client before doing anything. Any existing SharePoint or other CMS s deployed Quantity and skill level of the operations staff Policies with respect to server access, security, solution development and application lifecycle management Understand the current client and server hardware available, licensing that the client has, any 3rd party software applications Understand who the dedicated SharePoint staff, developers, business analysts, champions, etc Compliance, regulatory, external and internal user access policies Possible integration components

22 At the top of mind for any SharePoint Architect Solution, Infrastructure, Information and Logical Architecture Don t start the project until the elements above are conceived at least Think long term think Scalability and Performance! Integration Points (current and future) Content Inventories Growth estimates Why? Flexibility, Boundaries & Limitations

23 Boundaries and Limitations Limit Name Web application limits SharePoint 2010 Maximum Value SharePoint 2013 Maximum Value Web application Not Published 20 per farm Content database 300 per Web application 500 per Web application Zone 5 per Web application 5 per Web application Managed path 20 per Web application 20 per Web application Solution cache size 300 MB per Web application 300 MB per Web application Site collection (sites and sub-sites) 250,000 per Web application 250,000 per Web application Web server and application server limits Application pools 10 per Web server 10 per Web server Content database limits More Info: harepoint-2010-vs--sharepoint Boundaries-and-Limits-Comparison Number of content databases 300 per Web application 500 per farm Content database size (general usage scenarios) Content database size (all usage scenarios) Content database size (document archive scenario) 200 GB per content database 200 GB per content database 4 TB per content database 4 TB per content database No explicit content database limit No explicit content database limit Content database items 60 million items including documents and list items 60 million items including documents and list items Site collections per content database 2,000 recommended 5,000 maximum 5,000 recommended 10,000 maximum

24 How SharePoint 2013 can help with scaling Features to make it easier to scale to massive archives Remote Blob Storage Database query optimizations Internal timer job processing improvements New database indexing strategies, Minimal Download Distributed Cache, Highly scalable search, Request Management Shredded Storage Send deltas to BLOBS in SQL This allows: Tens of millions of documents and items in your single site collection Hundreds of millions of documents and items in a distributed archive allowing many site collections to bind together to act as one logical repository Fast searching

25 Structured Technical Analysis Early design decisions lay the architectural framework for the rest of your SharePoint deployment Alternatives and decisions analysis Selection and evaluation criteria List your alternatives List the pros and cons of each alternatives based on evaluation criteria Make your recommendation Use this for the tougher decisions you need to make, whether it is for an architectural decision or a a specific technical feature that must be implemented

26 SDLC and ALM Planning and System Setup Careful planning needed at the onset of SharePoint 2013 deployment on your strategy for Systems Development Lifecycle and Application Lifecycle Management Coding guidelines Apps model vs Server side coding Coding standards and checklists Organizational standard namespaces, strong keys and naming Source control strategy Issue/Bug logging strategy Continuous integration Use cases, User stories Test cases, Coded UI tests, Performance/load tests Release and Build management choose branching strategy Environments needed and promotions strategy (i.e. Workflows)

27

28 Office 365 vs On-Premises To cloud or not to cloud? That is the question It s NOT: OMG, move to the cloud now or ELSE you might be left behind by Microsoft (on-premises is NOT dead by any means) Gauge the technological maturity of your client and help them make the right decision for their business Don t follow the bandwagon and understand business sensitivity to the cloud Don t be bullied whose targets are based on getting you in the cloud Understand the migration costs and impacts for business critical applications Take a stab at the TCO of each before jumping in Evaluate the business case (skillsets, team costs, electricity, bandwidth, server costs, downtime, etc )

29 Physical vs Virtual Physical Underutilized resources remain idle while waiting instructions or not in use Higher costs purchasing, management and maintenance Reduced efficiency higher time to recover from outages < SLA Virtual Less powerful Easy to meet your changing business needs Great white paper on Best Practices for Virtualizing & Managing SharePoint 2013: ED51E /Best_Practices_for_Virtualizing_and_Managing_SharePoint_2013. pdf

30 App Model vs Traditional Choose wisely Farm Solutions Full trust solutions Access to file systems Classic model from 2007 Deploy to the GAC Access to the 14 Hive DLL s and.net Managed Code Sandbox Solutions Declarative elements Partially trusted code with limited API support DLL s and.net Managed Code No access to server Apps New Apps model Provider Deployed from corporate catalog Hosted or office market place Manage permission and licenses Auto X specifically Hosted Preferred option No server code! SharePoint Hosted Solutions Model App Model

31 Why did Microsoft go down the App Route? Get our code out of SharePoint! Easier to upgrade to newer versions/patches Create rich apps that tie into SharePoint but not dependent on it Allow developers to use any development platform they like! Reduction of: server outages and downtime errors due to custom code testing performance and scaling problems Fine grain control for administrators Office Marketplace and Cross-Device (i.e. Mobile and Tablets)

32 Extensive CSOM and REST API Coverage Start preparing your architecture for the future App Model is in it s infancy and is only going to get better, so why not try it out? Search Social Taxonomy Workflow Analytics Sharing Publishing ediscovery BCS And more..

33 External Access for Extranet and Internet Sites Be aware of the supported and tested extranet topologies with SharePoint 2013 Edge Firewall, Back to back perimeter, etc UAG and TMG are no more, Look at the new Web Application Proxy role in Windows 2012 R2 with ADFS 3.0 Great SP 24 session by Chris Johnson available on channel 9 in regards to web application proxy: Conference/2014/SPC333 Want more information?

34 Source:

35

36 Security concepts Use the principle of least privileges Minimum permissions that are required for users to complete authorized tasks SQL/SharePoint/Other managed, app pool and service accounts, roles Concept also applies to privileges within your SharePoint webs as well Security Hardening Service applications enabled per server role, ports, web.config, SQL, SMTP, Managed Accounts and auto password change Map your authorization and access to your Logical Architecture Could just be a spreadsheet, define groups and accounts that have access to which libraries and lists Want more information?

37 Understand capabilities and benefits of Claims Claims help you to factor authentication logic out of your applications An issuer can perform the authentication and provide tokens with sets of claims Tokens can be augmented with claims relevant to the user from other system ADFS is an easy to configure Issuer

38 Securing vs Targeting Targeting is NOT a form of security trimming Targeting allows the use personalization capabilities in SharePoint to show data relevant to the user i.e. Audience Targeting Capabilities Content Search Queries Just because data is not shown to the user, it doesn t mean the underlying data is secured any knowledgeable SharePoint user can trace where the data is A solid Information Architecture can reduce security risks Try to align Information Architecture site, list/library and folder structure with security groups if possible, will scale and be flexible in the future Look at securing information by claims

39

40 Virtual Machine and SQL Server Optimization VM s can be optimized for SharePoint deployments i.e. NUMA spanning, physical drives for SQL, index, etc. SQL Server Use a dedicated server if possible (Physical or Virtual) Set max degree of parallelism (MAXDOP) to 1 Server hardening Different fast physical drives for various types of databases (i.e. temp, logs, search) Separate out system drive Set initial DB sizes and higher auto-growth and consider multiple DB files Enable named pipes and TCIP in SQL Configuration Manager Use SQL Aliases in SharePoint installation to help in the long run Want more information?

41 Services running in multi-server environment You don t need to run ALL services on EVERY server (especially WFE s) Choose wisely which services are started on each server (i.e. Web App Service) Test out various configurations Think redundancy Use the services on server install worksheet as guidance Streamlined: Traditional:

42 Querying methods in SharePoint 2013 List view and metadata navigation SLOWEST Always access SQL so larger load Renders the most HTML Content Query Web Part VERY FAST Queries cached data via the Portal Site Map Provider so fast Least HTML rendered, Minor versions and within Site Collection Don t forget to filter your queries and only return what you need! Search Web Parts VERY FAST Offloaded to underlying search platform and querying against index Data is as current as most recent major version crawl but crawls full platform Learn how to use these! And concepts of display templates!

43 Caching The smallest caching tweak can have the most dramatic effect for users Blob caching - Page output caching MUST have for public facing web sites Also great for internal facing Object cache Content queries and content searches List views and rendering Configure SuperUser and SuperReader accounts! Important Custom development caching (i.e. in base master page or page layout): Server memory cache Distributed cache DO NOT USE SAME CLUSTER AS SHAREPOINT FARM

44

45 Consider Add-ons Huge SharePoint Partner/Vendor eco-system with some great easy to use, install and configure products: Governance (Huge time saver in long run) Backup/Restore RBS LMS Migration Records Management Security Analytics Etc

46 Connect with me on Visit my blog:

47 SharePint! Ce soir à 18h Le Trèfle, 3971 Rue Ontario E