This document is a first in a series on SharePoint 2010 Governance by Nilesh Mehta, Sr. SharePoint Architect @ NGenious Solutions, Inc.

1. Microsoft SharePoint Server 2010 Governance Date: 05/26/2011 Presented By: Nilesh Mehta Sr. SharePoint Architect NGenious Solutions, Inc. © 201-230-7922 | E-mail: Nilesh.Mehta@ngenioussolutions.com URL: http://www.ngenioussolutions.com

2. Agenda Defining SharePoint Governance What should be governed? Infrastructure Governance Application Development Governance

3. Microsoft Feedback “very detailed and take into account many of the important aspects of a SharePoint implementation that organizations are challenged with when deploying SharePoint. I can tell from reviewing these documents and from our discussions, that the team that wrote these documents are knowledgeable and experienced with SharePoint governance planning.” “that the governance documents provided are an outstanding foundation and starting point and will most certainly be very valuable during SharePoint farm implementation, and based on my personal experience and compared to other governance documentation that I have personally reviewed within other organizations, I would rate initial governance documents very high and above standard” - Microsoft

4. Defining Governance Governance is the process of identifying rules and guidelines that allow us to better manage our environment Governance is the process of defining what needs to happen and when it needs to happen Governance is an on going process

5. What needs to be governed? Following are different areas where governance needs to be implemented for SharePoint: Infrastructure Application Development Security and Compliance Training Communications

6. Infrastructure Server Build Service Accounts Services on the server SQL Server Web Applications Site Collections / Content Database Backup / Recovery Disaster Recovery Change Management Security management Managing multiple farms (DEV, QA, PROD) Documentation

7. Server Build Access to servers and central administration should be limited to SharePoint administrators only SharePoint 2010 uses the concept of Managed Accounts to run services on the server. Leverage different service accounts to run SharePoint services and DO NOT use individual user accounts for any SharePoint Services. SharePoint 2010 can automatically manage password policies for managed accounts to. However, we recommend this not be done for the MAIN FARM administration account, as in case of major issues, it will be important to know this username / password information for any recovery. SharePoint farm needs to leverage multiple service accounts. Grant permissions only as needed to these service accounts. Server monitoring using perfmon or SCOM or any other tools that you use internally.

8. Server Build Different service accounts should be leveraged for each separate farm. Servers should be kept up to date with latest service packs and security updates. Actually for SharePoint, I would recommend waiting at least a quarter before applying a service pack unless your immediate issues are being resolved by service pack. Follow your companies policies in hardening server security. Dedicate Servers for SharePoint usage only.

9. Server Build Services on the server: Understand how to setup different services In large environment, try to load balance services as much as possible Identify most used service and make sure it can scale, example: Search NOTE: User Profile Synchronization service cannot be load balanced

10. SQL Server If Possible and depending on your environment size, use a SQL Server cluster that will be dedicated for SharePoint usage only and will not be a shared environment, especially for Production environment QA / Development environment may be on single SQL servers and maybe part of Shared resources Maintaining enough free space on SQL will be one of the most important requirements for SharePoint, as it heavily depends on SQL. Recommend allocating 3 drives (minimum) for SharePoint databases. Drive 1: data Drive 2: Transaction Logs Drive 3: Backups For the data drive, the recommendation would be to always keep 1.5x disk free space on SQL.

11. Web Applications Depending on size of farm, potentially have following web applications: Collaboration My Sites Custom Applications Do not create unnecessary web applications just for vanity URLs. Leverage Host Header site collections

12. Site Collections / Content Databases Define Site Quotas upfront Group similar sites in a single content database. Some recommendations would be: Group by High Priority Sites Group by Large size sites Group by Custom application sites Group by regular collaboration sites Keep large sites at a maximum of 20 GB

13. Site Collections / Content Databases Keep Content Databases to be around 200-250GB size maximum For Example, at 2GB starting quota, you can host a 100 Site Collections within a single content database 2nd stage or Site collection recycle bin does not count against the site quota limit, so in this given example you could potentially gain another 100 GB of DB size if using the default recycle bin settings. As the number of site collections in a content database grows, keep an eye out for sites that are growing larger in size. Re-adjust your content database limits based on the size of each site at regular intervals.

14. Site Maintenance Implement a consistent Site Creation Process If SharePoint is new within your organization or if your organization is new to Microsoft Solutions, maybe start with few site templates (Team Site, Blog, Wiki, Search) to begin with Slowly start demonstrating features with Publishing, Business Intelligence, Content Management Monitor Site requests and make sure end users are requesting site with legitimate usage and not just play grounds Be able to generate report on who is requesting sites and how often are these used. Identify SharePoint roles that will be made available: Site Collection Administrator, Owner, Designer, Approver, Contributor, Read Only, Custom

15. Site Archival / Deletion Implement a policy for: Site Archival: When can / will a site be archived? What does archival mean? Backed up and deleted or will you be able to put a stub in place? If end users has links marked as favorites, what will be their experience? Site Deletion: When can / will a site be deleted? What will be your SLA for maximum amount of time a backup is made available for restore? What if end users only want certain parts of their sites restored?

16. Backup / Recovery NOTE: Keep at least 2 good backups on disk for quick data recovery

17. Disaster / Recovery Disaster recovery refers to restoration of services after hardware failure, man-made disasters, or natural disasters. To totally restore a server farm, the following SharePoint Server 2010 components must be backed up, scripted, or thoroughly documented: Separate farm for disaster / recovery. Make sure SQL databases are replicated properly. Solutions are deployed to all farms equally and regularly test that at least all content and customization in the DR farm. Central administration backups for entire farm Configuration database and Central Administration content database via native SharePoint tools. NOTE: It is not supported to restore the configuration DB using a tool such as SQL from a point in time. Content databases SharePoint 14 hive customizations Inetpub customizations such as web.config, and bin directory DLL’s

18. Disaster / Recovery Alternate Access Mappings (AAM) (cannot be restored via native tools) IIS for every Web Front End server Global Assembly Cache for each server Recommendations: All configuration changes and customizations must be documented to plan for disaster recovery scenarios and ensure adherence to governance policies (SharePoint 14 Hive, Inetpub, and alternate access mappings)

19. Change Management The purpose of change management governance is to: Define how changes will be tracked, catalogued, and approved Decide where older versions of configurations, code, and compiled components will be stored

20. Manage Multiple Environments Production / QA / Development: Leverage different service accounts for each farm for security Make sure QA mimics Production as much as possible All environments should be same in terms of platform updates, service packs, hotfixes and SharePoint 2010 Feature Set, as far as possible

21. Documentation Following components should be documented as part of the initial build (includes but not limited to): All documentation associated with the SharePoint environment should be stored in a central location. All configuration and customization tasks to the SharePoint environment should not be closed until the appropriate documentation changes have been completed. System infrastructure should be documented including: Network and System administrators Operating System installation specifics Third-Party Software Network Components Switches Routers Firewalls Storage area network (SAN) Cabling and electrical topology

22. Documentation Document the installation, configuration, and customization of the system in its environment. The system must be documented well enough so as to be reinstalled and reconfigured to last known good operating standards, should it become necessary to do so. Initial installation setup should be documented including: Installations file location and license key. NOTE: It is recommended to build a slipstream media that has latest updates for SharePoint included to help build new servers. Version number Farm servers (name, role, IP information) Service Accounts IIS configurations including host headers, assigned IP addresses, and SSL certificates Installation options

23. Documentation Initial farm configuration should be documented including: Services on servers Outgoing mail Logging and reporting settings Web applications (Include Web application general settings) Farm administrators and web application security policies Service application settings My Site Settings Search settings Scheduled tasks (profile synchronization, Index crawl, audience compilation, backup, etc.) Error resolution steps

24. Documentation Continually update server documentation with post-installation changes to your farm environment including: Service packs and upgrades plus associated version number Farm server additions or modifications (name, role, IP information) Farm operation or application configuration setting modifications Farm customizations should be documented including: SharePoint 14 Hive modifications IIS configurations including host headers, assigned IP addresses, and SSL certificates, web.config files, and other file customizations or additions to the Web application’s files Custom solution and applications deployed to the farm(s) Custom or 3rd-party web parts, add-ins, or solution deployment

25. Documentation Document custom solutions / applications that are deployed to the farm Document information across various environments like Development, UAT and Production Generate Site Owner information and share with Service Desk Generate information on sites that have broken inheritance in terms of permissions and share with Service Desk Teams or these teams should have access to this information on an as needed basis.

26. Questions? Date: 05/26/2011 Presented By: Nilesh Mehta Sr. SharePoint Architect NGenious Solutions, Inc. © 201-230-7922 | E-mail: Nilesh.Mehta@ngenioussolutions.com URL: http://www.ngenioussolutions.com