sharepoint operating model - final

SharePoint Server 2010 Operating ModelDeloitte Canada SharePoint 2010 deployment

Prepared for

Deloitte Canada Friday, 28 April 2023

Version 1.0 Final

Prepared by

Radu VaduvaPrincipal Consultant

[email protected]

Page iSharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 0.4 FinalPrepared by [email protected]"document.docx" last modified on 25 Jul. 12, Rev 2

Revision and Signoff Sheet

Change Record

Date Author Version Change reference

July 11th, 2011

Radu V. 0.1 Draft template document for the Operating Model.

Aug 26th, 2011

Radu V. 0.2 Draft document for review.

Sept 6th, 2011

Radu V. 0.3 Final document for review by the team.

Sept 21st, 2011

Radu V. 0.4 Incorporated all feedback from the core team into the document. This version has Track Changes on so that all of the changes made are clearly visible.

Sept 21st, 2011

Radu V. 1.0 Final version of the document with all of the core team feedback incorporated. All of the changes from version 0.4 have been accepted.

Reviewers

Name Version approved Position Date

© 2010 Microsoft Corporation. All rights reserved. The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication and is subject to change at any time without notice to you. This document and its contents are provided AS IS without warranty of any kind, and should not be interpreted as an offer or commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented. The information in this document

Page iiSharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 0.4 FinalPrepared by [email protected]"document.docx" last modified on 25 Jul. 12, Rev 2

represents the current view of Microsoft on the content. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED, OR STATUTORY, AS TO THE INFORMATION IN THIS DOCUMENT.

The descriptions of other companies’ products in this document, if any, are provided only as a convenience to you. Any such references should not be considered an endorsement or support by Microsoft. Microsoft cannot guarantee their accuracy, and the products may change over time. Also, the descriptions are intended as brief highlights to aid understanding, rather than as thorough coverage. For authoritative descriptions of these products, please consult their respective manufacturers.

Page iiiSharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 0.4 FinalPrepared by [email protected]"document.docx" last modified on 25 Jul. 12, Rev 2

Table of Contents

1 Introduction.................................................................................................................1

1.1 Audience.................................................................................................................................2

2 Business Goals..............................................................................................................3

3 Technical Strategy........................................................................................................4

4 Teams..........................................................................................................................6

4.1 Strategy Team.........................................................................................................................6

4.2 Tactical Team........................................................................................................................10

4.3 Integration with DTTL Governance team..............................................................................13

5 Governance Policies...................................................................................................15

5.1 Information Governance Policies.....................................................................................16

5.1.1 Quota Templates.............................................................................................................................16

5.1.2 Site Structure...................................................................................................................................18

5.1.3 Self-Service Provisioning.................................................................................................................21

5.1.4 Permissions Management...............................................................................................................22

5.1.5 Asset Classification (Data Security)..................................................................................................28

5.1.6 Lifecycle Management....................................................................................................................30

5.1.7 Branding and Templates..................................................................................................................32

5.1.8 Data Protection...............................................................................................................................33

5.1.9 Customization Policy.......................................................................................................................33

5.1.10 Site Templates.............................................................................................................................39

5.1.11 Workflows...................................................................................................................................39

5.1.12 Sandboxing..................................................................................................................................42

5.1.13 Records Management.................................................................................................................43

5.1.14 Metadata Services.......................................................................................................................44

5.1.15 Fluid Application Model..............................................................................................................46

5.1.16 External lists................................................................................................................................47

5.1.17 Microsoft Business Data Connectivity (BDC)...............................................................................49

5.1.18 Language Support........................................................................................................................50

5.1.19 Publishing....................................................................................................................................52

5.1.20 Audit and content cleansing........................................................................................................53

5.1.21 Document Versioning..................................................................................................................54

Page ivSharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 0.4 FinalPrepared by [email protected]"document.docx" last modified on 25 Jul. 12, Rev 2

5.2 Development, Deployment, and Support Governance Policies............................................55

5.2.1 Development Environment.............................................................................................................56

5.2.2 Design Goals....................................................................................................................................58

5.2.3 Development Process......................................................................................................................59

5.2.4 Versioning and Source Control........................................................................................................60

5.2.5 Deployment Method.......................................................................................................................61

5.2.6 Features..........................................................................................................................................62

5.2.7 Use of SharePoint Designer 2010....................................................................................................64

5.2.8 Use of SharePoint Client Technologies Like Silverlight....................................................................65

5.2.9 Functional (Unit) Testing.................................................................................................................66

5.2.10 Deployment to Test and Production............................................................................................68

5.2.11 How to Package WSP...................................................................................................................69

5.2.12 How to Deploy Web.config Entries..............................................................................................70

5.2.13 Feature Cleanup..........................................................................................................................70

5.2.14 Hotfix Support.............................................................................................................................71

5.2.15 Development Roles.....................................................................................................................71

5.2.16 SharePoint Farm Environments...................................................................................................72

5.2.17 Support........................................................................................................................................73

5.2.18 Logging........................................................................................................................................74

5.3 Security Policies.................................................................................................................76

5.3.1 System Administrator......................................................................................................................76

5.3.2 Backup Administrator......................................................................................................................77

5.3.3 SharePoint Farm Administrator.......................................................................................................77

5.3.4 Enterprise Site-Collection Administrator.........................................................................................78

5.3.5 Other Security Policies....................................................................................................................78

6 Infrastructure Operations & Monitoring.....................................................................79

6.1 Microsoft Operations Framework (MOF)..............................................................................79

6.2 Monitoring SharePoint..........................................................................................................80

6.3 Patching and hot fixes...........................................................................................................81

6.4 System Centre Operations Manager (SCOM) 2007...............................................................82

6.5 Farm Administrator and SQL Administrator Policy...............................................................83

6.6 Enterprise Site-Collection Administrators.............................................................................83

6.7 Changing Passwords.............................................................................................................84

Page vSharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 0.4 FinalPrepared by [email protected]"document.docx" last modified on 25 Jul. 12, Rev 2

6.8 Database Maintenance.........................................................................................................85

6.9 Applying Patches...................................................................................................................85

6.10 Managing Log Files............................................................................................................86

6.11 Monitoring and Cleaning Up Sites.....................................................................................86

6.12 Enforcing Site and Content Size Limits..............................................................................87

6.13 Backup Policies..................................................................................................................87

6.14 Disaster Recovery..............................................................................................................89

6.15 Custom Governance Policies.............................................................................................91

<<Custom Policy>>.......................................................................................................................................91

7 Training Plan..............................................................................................................92

7.1 Openly Available Microsoft Training & Resource Material...................................................93

7.2 Training providers.................................................................................................................96

8 Individual Roles and Responsibilities..........................................................................97

9 Governance Tools.....................................................................................................102

10 References............................................................................................................103

Page viSharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 0.4 FinalPrepared by [email protected]"document.docx" last modified on 25 Jul. 12, Rev 2

000Deloitte Canada0

1 IntroductionThe Operating model or Governance Plan is a guidebook outlining the roles, responsibilities, and policies necessary to support Microsoft® Office SharePoint® Server 2010 Products and Technologies environments. It identifies lines of ownership for both business and technical teams, defining who is responsible for what areas of the system. Furthermore, it establishes rules for appropriate usage of the SharePoint environments.

An effective governance plan determines that the system is managed and used in accordance with its designed intent to prevent it from becoming an unmanageable system. The management of an enterprise-wide system involves both a strategic, business-minded board to craft rules and procedures for the use of the system and also a tactical, technically competent team to manage the routine operational tasks that keep the system running. Users of the system will be empowered by a support and developer community sponsored by the business leaders.

The governance plan document contains the following:

Teams that define and enforce policies, roles, and responsibilities associated with a SharePoint solution.

Policy definitions. SharePoint Server 2010 features used to enforce policies.

The governance plan document should only contain policies that CAN and WILL be enforced. The governance plan document should NOT contain implementation details, network requirements, and feature requirements.

A training plan needs to be developed to train the users of the system to realize maximum return on investment in a SharePoint Server 2010 solution. A comprehensive training plan should include training workshops online and in person to use SharePoint Server 2010 according to the governance policies. It is critical to explain to the users why those standards and practices are important. The plan should cover the complete spectrum of training necessary for specific user groups to general user base. For certain types of roles, specific and more advanced training needs to be mandatory.

When governance is properly implemented with SharePoint Server 2010 solutions, the following statements are true:

Governance teams review and proactively act based on usage data and business needs. Business users are assured of protected data, and the security model is known and

enforced. Service-level agreements (SLAs) are in place, platform performance is good, and any custom

code is well tested. Sites are systematically introduced using site templates and created by designated

authorities. The growth of the server farms, servers, and storage is predictable.

For additional information about these four aspects of governance, see the Governance Guide provided as part of the Platform Services Service Line Offering.

Page 1SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 0.4 FinalPrepared by [email protected]"document.docx" last modified on 25 Jul. 12, Rev 2

000Deloitte Canada0

1.1 AudienceThis document is intended for the all the stakeholders involved in the governance of SharePoint Server 2010 products and technologies at Deloitte Canada. This includes business stakeholders, IT administrators, solution development teams, site-collection administrators, and anyone else involved in defining or enforcing governance policies. Within Deloitte Canada, the audience includes the SP&E Portfolio Managers, the Client Service Leads, Enterprise Architecture under SP&E, Collaborative Solutions Group and Application Systems, and any service owners like the KMO.


000Deloitte Canada0

2 Business GoalsAs stated earlier, SharePoint 2010 should be used only where there is a clear business need. It will be the responsibility of the governance team to collectively seek out business opportunities to enhance. In several organizations, the need for SharePoint Server 2010 deployment to further business goals may originate from managers as well. It is important to seek out the objectives and goals from front-line managers in these organizations. The team will ask questions such as:

How do we improve business processes, and how do we deliver on that? What structures need to be in place to deliver this value? What areas of the business offer the most opportunity for growth? How can we align our activities with the goals of the business? Are there synergies that can be created between divisions and departments? What groups are doing similar initiatives, and how can we help? What ways can we reduce inefficiencies and duplication? How can we meet compliance requirements?

As described in the Architecture Roadmap document, Deloitte Canada has a few immediate business goals. One of the most important is that the SharePoint 2010 infrastructure platform will have a governance plan. This document is the beginning of this plan. A few notable additional goals are:

Integration with the Global infrastructures and deployment of SharePoint 2010 to harness the global content available;

Rationalization of applications and platforms by consolidating all of the various SharePoint farms that exist within the Deloitte Canada environment;

Focus on a single platform, SharePoint 2010, to address business requirements and implement solutions where the features fit the capabilities.

Support the Operation Excellence initiatives across Deloitte Canada.

The answers to the questions above are addressed throughout this document, in the sections that follow. For example, the structure of the recommended teams to govern the SharePoint 2010 platform is described in section 4 named Teams. In addition to the recommended team structure, a recommended interaction model is included in section 4 to describe how the various programs and projects leveraging the SharePoint platform are integrated into the processes, procedures, and policies definitions.


000Deloitte Canada0

3 Technical StrategySome of the things to consider when putting together the SharePoint governance strategy are:

What will be the defined taxonomy? Will it be managed centrally, at the department level, or site level?

How many farms will we need? How will search be managed? What scopes should be available? What content sources

should be crawled? How do we manage “best bets”? Who will manage security? Which SharePoint 2010 Service Applications will be needed? Do we need quotas for sites? What should that quota be? How do quotas differ between

project sites/team sites/other potential sites to be deployed on SharePoint? What level of backup and recovery is needed? Who will manage this process? Will we need

third-party tools? Who will monitor the health of the system? What monitoring tool will be used? What types of content will we allow? Are blogs and wikis allowed by organization policies?

What about social-networking features? Who will manage the content? What happens to dormant sites? Will there be integration of external systems? How will this integration happen, and who will

manage this integration? What is the security on integration of external systems? What is the storage policy of structured and unstructured data? Do we need to plan for

External BLOB Storage (EBS) and Remote BLOB Storage (RBS)? What is the archival policy? What is the records management policy regarding documents? Differentiate file share, online storage, and SharePoint storage. Do we need records management? What are the data-retention and data-leakage policies? How do we satisfy compliance requirements? Record the future direction statements for the architecture, operations, collaboration, and

information strategies.

The answers to the above questions are provided throughout this document and reflected in the Governance policies, Infrastructure Operations & Monitoring, Training plan, and Individual roles and responsibilities sections of the document. The sections that address these questions are:

1. Taxonomy definition can be found in sections: Site Structure and Metadata Services. The taxonomy will be managed at the service level (for example Internal and External team site service) as well as the site level.

2. Two production SharePoint 2010 farms will be required to address the current Deloitte Canada needs: an Internal SharePoint 2010 farm and the DOL/External Team Site service farm. The Infrastructure Operations section covers the environments as well as the need to have separate environments.

3. Search management is provided by the KMO team who is part of the Strategy team. The search components management, as FAST Search for SharePoint 2010 is used, is covered in the governance of the Enterprise Search.


000Deloitte Canada0

4. Security management is covered in section 22 Permissions Management. Security management for the identified services is available in this document. Additional security management policies must be identified as new solutions and applications are deployed. This document must include either references to security management of solutions or applications or the policies of those solutions and applications.

5. The Service Applications to be used within the internal, production SharePoint 2010 farm are documented in the Architecture Roadmap document. Additional information is provided in section 5.2.16 SharePoint Farm Environments.

6. Quota policies for existing SharePoint 2010 services such as internal and external Team Sites are defined in section 5.1.1 Quota Templates. Additional guidance for creating quota templates for new services or applications is provided in the same section.

7. Existing and new, recommended backup and restore processes and procedures are documented in sections 6.13 Backup Policies, 5.3.2 Backup Administrator, and 6.14 Disaster Recovery.

8. Monitoring policies and tools to be used for the SharePoint 2010 environments are documented in a few sections across 6 Infrastructure Operations & Monitoring.

9. The types of sites and content that will be allowed in SharePoint 2010 include blogs, wikis, team sites, and the default file types included in the policy of the default SharePoint 2010 installation.

10. The policies and recommended processes to identify dormant sites and manage site content is described in sections 5.1.5 Asset Classification (Data Security), 5.1.6 Lifecycle Management, 5.1.13 Records Management, and 5.1.3 Self-Service Provisioning.

11. Policies regarding integration with external systems and the security processes around integration with external systems are documented in sections 5.1.15 Fluid Application Model, 5.1.16 External lists, 5.1.17 Microsoft Business , and 5.2 Development, Deployment, and Support Governance Policies.

12. External blob storage is not recommended for the content targeted for the SharePoint 2010 farms. However, storage policies and guidelines are outlined in sections 5.1.8 Data Protection, 5.1.1 Quota Templates, and 6.12 Enforcing Site and Content Size Limits.

13. Archival and records management policies are defined throughout sections 5.1.6 Lifecycle Management, 5.1.13 Records Management, and 6.11 Monitoring and Cleaning Up Sites.

14. Deloitte Canada has a good understanding of the type of content that should be uploaded and hosted in SharePoint. The internal and external team sites host content that practitioners and clients will collaborate on. Records management and archival policy recommendations are provided in this document. Additionally, further policies will be defined and implemented once the OpenText Content Server implementation is started.

Overall, the direction for SharePoint Server 2010 at Deloitte Canada revolves around having the proper farms in place to support both team service offerings and internal initiatives. The operations of the farms will be provided by the existing SharePoint support team (CAS) with new processes and procedures for the new features and capabilities. Information management and taxonomy will be implemented in conjunction with the KMO and the team’s processes and procedures. Additional features available in SharePoint Server 2010 may be leveraged to expand certain service offering features such as allowing end users to submit terms into the Deloitte taxonomy.


000Deloitte Canada0

4 TeamsSharePoint environments will be managed by two teams: a strategy team and a tactical team. Regardless of what name we ascribe to these teams, they will play distinct roles and have distinct responsibilities.

4.1 Strategy TeamThis team consists of appropriate business owners willing to provide strategic insight and direction for the portal and who can drive strategic initiatives into their respective organizations. Resources represent a good balance between business and IT and also centralized control versus decentralized empowerment.

This team could also be called the SharePoint Governance Board. This board serves as a governing body with ultimate responsibility for meeting the firm’s goals with respect to SharePoint. This board typically comprises representatives of each of the major service line represented in SharePoint.

Guidelines about setting up this team:

It needs to have a coordinator, typically with a project-management background, to run the meetings and follow up on actions.

The executive sponsor must be a member of this team. It’s typically a CIO or the IT director. If this is a central board for the organization, business owners (Client Service Leads) of

SharePoint from all departments should have representation on this team. The team must meet at least quarterly to review the policies and updates. The team may have rotating membership to infuse fresh perspective.

The diagram below highlights the recommended process for addressing additional features or capabilities or changes to the current governance policies as required by new business programs or projects such as ICD, O&E, Gateway, etc.


000Deloitte Canada0

Figure 1 Recommended process for additional business requests

Based on the current governance policies and procedures, as documented here, certain features and capabilities are to be used by any program or project in a certain way. However, it is important to have a process in-place for addressing additional feature and capability requirements across the platform. The tactical team is the front-line of engagement with the program and project teams. There are two scenarios where the tactical team must refer to the Strategy team for direction/approval:

1. The program or project teams request new features or capabilities be enabled in the SharePoint 2010 farm;

2. A common request is submitted for a new feature and capability.

In both cases, the governance policies either block the use of such capability/feature or require an extensive process. The requests for new features and capabilities should be captured in order to determine uniqueness or commonality. New features and capabilities should be addressed not only in the infrastructure but also have governing policies implemented. For example, if requests are made for access to the same, standard Siebel web service from internal SharePoint sites, it may be worth implementing a specific rule around exposing the specific web service instead of running through the process every single time. At the same time, the request process can be tracked to ensure a secure and compliant environment is operated when it comes to exposing customer and business information.

Role Name Responsibilities

Coordinator <<insert name here.>> Project-management responsibilities of ensuring that the team is functioning smoothly, meeting at an appropriate frequency, and the follow-up on the


000Deloitte Canada0

decisions is promptly done.

Executive Sponsor Stephen Mansfield Provides executive-level sponsorship for SharePoint. The primary responsibility of the Executive Sponsor is strategic, positioning SharePoint as a critical mechanism for achieving business value and helping to communicate the value of the SharePoint environment to the management levels of the organization.

SP&E Representative Responsible for managing the overall design and functionality integrity from Service Request and Enterprise Architecture perspective. The representative also defines policies for SharePoint services that relate to Enterprise Architecture and portfolio management.

Human Resource Representative <<insert name here.>> Responsible for portal and content compliance with HR mandates. Assists with creation of compliance policy. Assists with educating users about usage policies and, in case of enforcement, works with the managers.

Legal Department Representative <<insert name here.>> Responsible for portal and content compliance with legal mandates. Assists with compliance-policy creation. Educates users on compliance law. Audits and enforces compliance.

KMO Representative Responsible for portal and content taxonomy as well as content publishing standards. The representative also defines policies and procedures for the internal team sites shared service. (External team sites)


000Deloitte Canada0

Assurance & Advisory CSL Managing the overall design and functionality integrity of SharePoint from a business perspective. The SharePoint Business Owner doesn’t have to be an IT expert, but the job function typically includes responsibility for internal communications, intranet portals, external communications, and external portals.

Consulting CSL Managing the overall design and functionality integrity of SharePoint from a business perspective. The SharePoint Business Owner doesn’t have to be an IT expert, but the job function typically includes responsibility for internal communications, intranet portals, external communications, and external portals.

Enterprise Risk CSL Managing the overall design and functionality integrity of SharePoint from a business perspective. The SharePoint Business Owner doesn’t have to be an IT expert, but the job function typically includes responsibility for internal communications, intranet portals, external communications, and external portals.

Financial Advisory CSL Managing the overall design and functionality integrity of SharePoint from a business perspective. The SharePoint Business Owner doesn’t have to be an IT expert, but the job function typically includes responsibility for internal communications, intranet portals, external communications, and external portals.


000Deloitte Canada0

Tax CSL Managing the overall design and functionality integrity of SharePoint from a business perspective. The SharePoint Business Owner doesn’t have to be an IT expert, but the job function typically includes responsibility for internal communications, intranet portals, external communications, and external portals.

Table: Governance Strategy Team

4.2 Tactical TeamThe tactical team consists of three sub-teams, all charged with supporting the directives of the strategy team:

Operations Support Development

In addition to the three sub-team roles defined below, it is important to ensure there are business users who have SharePoint knowledge in order to:

Map business requests to SharePoint features (at a high-level). The Business Analyst role is specifically targeted for this task.

Track end user training requirements, end users only Create storyboards and mock-ups based on SharePoint capabilities rather than generic web

site designs.

The Business area in the diagram below depicts the three (3) additional roles recommended for the Tactical team. These roles (SharePoint Business Analyst, SharePoint Creative Designer, and SharePoint Trainer) should be considered in addition to the tactical roles defined below.

Note

The 3 business roles that part of the Tactical team do not need to be exclusive to the SharePoint platform deployed at Deloitte Canada. These roles can span across multiple technologies


000Deloitte Canada0

Figure 2 Business users recommended for SharePoint deployments

The following diagram represents the current supporting organizational structure in place at Deloitte Canada and the recommended mapping of roles and responsibilities to support the SharePoint governance.


000Deloitte Canada0

Figure 3 Tactical Team structure at Deloitte Canada

The structure addresses the needs for a Tactical team and has some role representation from the Strategy team.

Team Representative Title Name Responsibilities

Operations System Administrator

Collaborative Applications Systems (Karen Gajadhar)

Define the governance policies around quotas, security and permission, infrastructure (hardware, OS, and so on), and backup and restore.

Operations Microsoft SQL Server® Administrator

DBA Support(Fraser Galer)

Define the governance policies around SQL Server configuration, SQL Server backups and restores, SQL stored procedures, log management, and SQL tuning.

Operations Security Resource SP&E Security(Fasil )

Define the governance policies for Active Directory® directory service use and synchronization.Define the governance policies for ensuring the solution is satisfying security compliance requirements such as HIPAA, PCI, and GLBA.

Support Support Lead Support Service desk Define the policies for support


000Deloitte Canada0

(Amanda Palma) escalation.

Development Development Manager

Working Committee composed of: Nick, Ray, Stephen, Aditi Soory and the US-I technical lead. A lead for this committee must be selected.

Define the governance policies associated with the development environment and processes used for development. Responsible for guidelines around coding, code review, customization, security, and performance.

Development Architect Collaborative Solutions Group (Aditi Soory)SP&E Enterprise Architecture (Niko Kapetanios)SP&E Technology Architecture(Fraser Galer)SP&E Security (Martin Mroczek)

Define the governance policies associated with architecture and design of solutions and policies around deployment of the solution. The governance policies associated with the design and architecture of solutions must include a securityaspect.

Development Test Manager Test Group(Tracy Patterson)

Define the governance policies associated with the test environment and processes used for testing and releasing criteria. Responsible for guidelines around defect classification and defect tracking and management.

Development User Experience Manager

Collaborative Solutions Group(Uday)

Define the governance policies associated with user interface and navigation guidelines.

Table: Governance Tactical Team

4.3 Integration with DTTL Governance teamAt the time of this document’s writing, a global Deloitte team was established for the governance of SharePoint 2010 across all member firms. The diagram below describes the recommended interaction between the Deloitte Canada SharePoint governance teams and the Global SharePoint governance teams. The recommended interactions ensure Deloitte Canada requirements, concerns, and issues are well represented and supported at the global level. At the same time, with any new solutions or applications developed for Deloitte Canada Services, leadership in the platform use can be showcased at the global level.


000Deloitte Canada0

Figure 4 Recommended Deloitte Canada interactions with Global SharePoint governance teams


000Deloitte Canada0

5 Governance PoliciesEach type of site has more or less overall impact within an enterprise. As a result, each type has a greater or lesser need for governance policies and more or fewer policies as a result.

The following sections describe governance policies within categories. This guidance highlights considerations for each policy. Your policies should be described with succinct and clear statements that dictate who, what, when, where, and why.


Enterpris

e Portal,

Internet Site

Business Unit Portals

Collaboration Sites

Project Sites

My Sites

Define or Update Policies

Implement Policies

According to Definition

Enforce Policies

Measure & Analyze

Effectiveness

Impact (number of users accessing, availability, and so on)

Governance Policies

000Deloitte Canada0

5.1 Information Governance PoliciesDefining information-governance plans requires an understanding of the site topology, the purpose of each Offering (like internal or external team sites), and preferably a knowledge of future planned Offerings, such as My Sites.

Information policies need to be defined for each site within the SharePoint deployment. A policy needs to be defined per topic area for each site Offering.

5.1.1 Quota Templates

Purpose

Many organizations have many site collections deployed in a SharePoint Server 2010 farm. Additionally, the management of site collections is often delegated to department or business-unit administrators to reduce the overall burden on the IT staff. Without governance, site collections can grow in size and exceed disk space capacity or grow beyond the limits of architectural designs, which can slow performance.

Defined By

System Administrators (CAS), Business Owners (such as KMO), Architects (Enterprise Architecture)

Policy Definition

There are multiple services available at Deloitte Canada. For any self-service provisioning of team or projects sites and my sites, quotas should be applied (through quota templates). Multiple tiers can also be created so that SharePoint storage can be properly assigned. The following tables outline site quota definitions. Unless otherwise requested by the site collection owner, the first quota template (identified as the default) should be selected when a site collection is created.

For internal and external team sites, the default site quota templates will be selected by default when the site is provisioned. Additional space will be provided upon request. The next site quota template in the tables should be used to determine the

Team Site Quota Templates (recommended limits)

The internal team site storage is managed by KMO. All of the requested team sites are assigned 1 GB (1000 MB) of storage. Template 1 below should be used to handle the initial requests. For additional storage requests, beyond 1 GB, a template should be used as well. It is important to define the growth steps allowed for the team sites in order to implement the required site quota templates. The definition for the quota templates should be completed in conjunction with the KMO team.

Quota template name

Limit site storage to a maximum of

Send warning e-mail when site collection storage reaches

Limit maximum MB usage per day to

Send warning e-mail when MB usage per day reaches

Template 1 (default)

1000 MB 900 MB 300 200

Template 2 (TBD)

5000 MB 4500 MB 500 400


000Deloitte Canada0

Template 3(TBD)

10000 MB 9000 MB 1000 800

External Team Site Quota Templates

The planned external team site default site quota is 2 GB (2,000 MB). As is the case with the internal team sites, a process exists for requesting additional storage. KMO reviews the requests and the business justification and approves the request to be implemented. Additional site quota templates should be defined for additional storage requests. The site quota templates should be defined in conjunction with the KMO group to ensure it meets growth patterns.

Quota template name





Template 1 (default)

2000 MB 1800 MB 300 200

Template 2(TBD)

5000 MB 4500 MB 500 400

Template 3(TBD)

10000 MB 9000 MB 1000 800

MySite Quota Templates

MySite quota templates should have no layered storage service provisions, i.e. a single MySite storage allocation should be assigned per employee. A site quota template should still be used in case future increases are required. The quota template also helps with controlling the size of the upload to MySites.

Quota template name





Template 1(default)

TBD TBD TBD TBD

Note

When planning MySite quota templates, the following factors must be taken into consideration:

- Number of employees: currently, 8,000

- Maximum number of web applications: 1

- Maximum number of content databases: 300

- SLA for MySite restore based on current procedures


000Deloitte Canada0

For example, if a maximum of 500 MB is assigned per user, then the total database storage required will be 4 Terabytes (500 MB * 8,000 = approx. 4,000 GB = 4 TB. The calculation is based on full capacity reached by all users in all MySites. In order to keep the content database size to 150GB, as is the case with all other content databases, approximately 27 content databases should be provisioned (4,000 GB / 150 GB = approx. 27).

Additional Service Quota Templates

Any additional service offerings should use the following template to define site quota templates.

Quota template name





Template 1(default)

1000 MB 800 MB (or 80% of the maximum limit)

300 (or 3% of the maximum site size)

200 (approx. 80% of the maximum MB usage per day)

Template 2

Key Considerations

Quotas are often exceeded when:

People upload unnecessary data. File sizes are significantly larger than predicted. An archiving solution is not properly designed. (This is the most important of these

considerations to anticipate.) SharePoint may not be the best long-term approach for data that must be retained

solely for governance or industry regulations. In these cases, it may make sense to archive the data outside of SharePoint Server 2010. For example, the OpenText Enterprise Library (part of the Content Server) should be used for content archiving.

5.1.2 Site Structure

Purpose

This is an information-architecture planning task but governance is required to enforce consistent usage of the site over time.

Defined By

Information Architect or Architect (SP&E Enterprise Architecture and Collaborative Solutions Group), KMO

Policy Definition

For every custom application or solution or shared collaboration service running on SharePoint 2010, a site structure must be defined. There are multiple site structure policies defined in this document based on the sites and services implemented.


000Deloitte Canada0

Note

It is important to note that site structure will impact not only the navigation within a site but could also impact the overall farm health and performance.

The following diagram shows the hierarchy that should be considered when implementing new service offerings or custom applications. It is important to also understand the limits at each level. For detailed information on recommended limits please see the Architecture Roadmap document or the following link: http://technet.microsoft.com/en-us/library/cc262787.aspx.

Figure 5 SharePoint 2010 Hierarchy

Team Sites

Every team site request must have an identifiable Service associated with it. Using the service for which the team site is requested, a team site should be created as a site collection under the appropriate web application. All of the sub-sites for team site will be created under the site collection. Six (6) web applications are recommended for the internal team sites roll out. The Deloitte (Collaboration) Team Sites web application can be used by teams or departments that do not fall within the five standard Services. Alternatively, any team site created for collaboration between groups in two separate Services can use this web application.

All other team site should be provisioned under the appropriate Service web application.

Note

As the maximum recommended number of content databases per web application is 300 and the maximum recommended number of site collections per content database will depend on the size of the sites requested, additional web applications may be required.


Web application

Content Database

Site Collection

Site (sub-site)

http://technet.microsoft.com/en-us/library/cc262787.aspx

000Deloitte Canada0

Ensure a process is setup to monitor and plan for provisioning new web applications when the limits are approached.

Figure 6 Recommended Internal Team Site structure

External Team Sites

External Team Sites will be used by Deloitte Canada practitioners to collaborate with external customers on services engagements. When an external team site is requested, a new site collection must be created for any new engagement with the customer. The site collection must reside under a separate web application dedicated to external team sites. The service lines can be used for the external team sites to ensure enough web applications are available to handle the number of content databases and site collections to be created.

MySite sites

There is a single web application created for the MySite deployment at Deloitte Canada. All MySite site collections should be created under a single web application, for example http://my. Every single employee with a MySite site should only be allowed to create sub-sites based on Deloitte allowed site templates. The site structure of individual MySites should be left up to the end user but training must be provided to the end users to ensure sub-sites are only created if needed. Additional sub-sites within a MySite could rapidly increase the storage consumed and take the site collection to the maximum dictated by the site quota.

Other SharePoint Sites and Custom Applications


http://my/

000Deloitte Canada0

Individual solutions or custom applications will have their own requirements for site structures. It is important to understand all of the facets of the site structure and the impact is has on performance before deploying an application in the environment.

Key Considerations

No specific considerations.

5.1.3 Self-Service Provisioning

Purpose

SharePoint Server 2010 implementations can overwhelm help desk and IT staff if not well governed. An example of this is when unnecessary requests are escalated to the help desk or IT staff for site creation. It is usually beneficial to allow for automatic provisioning of new sites, but you also want to convey that you have the proper controls in place to limit when sites can be automatically provisioned.

Defined By

Architect (Enterprise Architecture and Collaborative Solutions Group), System Administrators (CAS), KMO

Policy Definition

Self-service provisioning is not allowed in any of the SharePoint environments at Deloitte Canada. A certain process, as defined by the KMO, must be followed to have a team site provisioned.

Key Considerations

Self-service provisioning requires strong processes, policies, and support tools to maintain the size of the content stored in SharePoint. There are two recommended approaches to self-service provisioning:

1. Allow self-service provisioning: this approach requires strong processes and tools to manage the content that will be created by employees on an ad-hoc basis. Processes for retiring old or stale sites must be implemented and appropriate tools must be used to manage the growing content in SharePoint. As self-service is enabled, it is recommended financial information is mandatory for every single site in order to allow for chargeback, in the future, if required. Moreover, a process to clean-up and decommission stale or expired sites must be implemented.

2. Disallow self-service provisioning: this approach requires an up-front process to receive team site requests and provision them. Moreover, a process to clean-up and decommission or archive sites is still required.

The tools to implement this type of process must include the following features:

1. Collect and store information about site collections, within site collections themselves or through reporting tools closely tied to the provisioning process. For example, site collection information can be stored using property bags through the SharePoint Object Model. This ensures the information is persisted throughout the lifecycle of the site collection.


000Deloitte Canada0

2. Report capabilities for SharePoint administrators to view top storage consuming site collections or sites about to expire.

3. Automatic operations implementation for taking appropriate actions based on the status or state of a site or site collection.

5.1.4 Permissions Management

Purpose

What permission levels are allowed, how are they implemented, and how are they managed over time.

Authorization in SharePoint 2010 is implemented based on permissions. Permission collections make up permission levels. SharePoint 2010 includes five (5) permission levels by default. The default permission levels can be customized (with the exception of the Limited Access and Full Control permission levels) or new, custom permission levels can be created to support the set of permissions required by a certain solution or set of users.

Defined By

System Administrators (CAS), Security Resource

Policy Definition

Permissions configured at the web application level must be set by the System Administrators (CAS) team in accordance with the Security policies and the requirements of the solution or service implemented. The permissions are controlled through the SharePoint Central Administration interface and only users with access to this tool must update the permissions per web application.


Web Application administrators define permissions available at the site collections under a certain site collection

Site collections created under a web application will have access to configure permissions configured at the web application level only

Create custom permission levels based on web application permissions and business requirements

000Deloitte Canada0

For any SharePoint 2010 collaboration service based on the team site template, the default permission levels provided must be used. These permission levels are listed below:

Permission level

Description Permissions included by default

Limited Access

Allows access to shared resources in the Web site so that the users can access an item within the site. Designed to be combined with fine-grained permissions to give users access to a specific list, document library, folder, list item, or document, without giving them access to the entire site. Cannot be customized or deleted.

View Application Pages

Browse User Information

Use Remote Interfaces

Use Client Integration Features

Open

Read View pages, list items and download documents. Limited Access permissions, plus:

View Items

Open Items

View Versions

Create Alerts

Use Self-Service Site Creation

View Pages

Contribute View, add, update, and delete items in the existing lists and document libraries.

Read permissions, plus:

Add Items

Edit Items

Delete Items

Delete Versions

Browse


000Deloitte Canada0

Directories

Edit Personal User Information

Manage Personal Views

Add/Remove Personal Web Parts

Update Personal Web Parts

Design View, add, update, delete, approve, and customize items or pages in the Web site.

Approve permissions, plus:

Manage Lists

Add and Customize Pages

Apply Themes and Borders

Apply Style Sheets

Full Control

Allows full control of the scope. All permissions

Collaboration services such as Team Sites and External Team Sites should use all of the above permission levels. Additional, custom permission levels can be created, by site collection or site administrators to address additional requirements.

SharePoint Server 2010 can leverage Active Directory users and groups to secure content and limit or allow site and site collection activities. Active Directory Security Groups or e-mail enabled Security Groups are the only groups supported by SharePoint Server 2010. Active Directory Distribution Groups (DGs) are not visible in the People Picker applications or any other SharePoint permission interface

Additionally, SharePoint groups can be used to further organize users into groups without the need to create Active Directory groups. This approach should be used when dealing with a small number of users for which a new Active Directory security group is not warranted. SharePoint groups are provided in addition to the Active Directory groups but should only be used for small number of


000Deloitte Canada0

users that are not in an Active Directory security group already. The number of users to be used for this limit is to be determined. Usually, a small number of users, for example ten (10), is the limit SharePoint groups should be used for.

In addition to using SharePoint groups for a small number of users not in an Active Directory security group, these can be used for any role segregation duties; for example, separating readers from editors for a specific application or solution. However, the limit of number of users should still apply.

The following diagrams list a few options for handling permissions and using Active Directory principals (such as Groups and Users) for securing SharePoint.

Figure 7 Options for permission management

When an end user needs access to a SharePoint site, there are multiple ways to allow the user access to the site. There are various considerations that come into play and must be carefully reviewed to ensure the permission and group management for SharePoint do not become an issue.

1. If the Active Directory user (End User accessing SharePoint Site) belongs to a security group that can be used to secure the SharePoint site (along with all the other end users who are part of the group) then the SharePoint Site Owner can use the group to either assign it direct SharePoint Permissions (assign the group a permission level) or add the Active Directory security group to the SharePoint group that has the appropriate permissions.

2. If the Active Directory user does not belong to a security group then there are two options:a. Create an Active Directory security group and add the user (along with any other

users who require access to the SharePoint site) to this group. Once the group is created in Active Directory, the instructions described in point 1 above can be used.

b. Add the end user to the appropriate SharePoint Group directly. This approach should be used when there is a single or a really small number of users who require access to the site. The minimum number of users should be predetermined prior to the release of the governance plan. The number should not be smaller than 10 in order to keep the number of Active Directory groups create just for SharePoint to a minimum.

3. If the Active Directory user belongs to a few Active Directory security groups but none of them can be used for the purpose of SharePoint site permissions as they would give more people more permissions than allowed. This would be the case if the Active Directory groups that the end user belongs to contain too many users or more than allowed to the


000Deloitte Canada0

SharePoint site. In order to solve this issue, the same approach as 2a or 2b above can be used.

Note

It is recommended a separate OU be used for setting up Active Directory security groups that must be created for use within SharePoint. This approach ensures a single location can be audited or administered for these groups. This approach may not work for existing Active Directory groups within Deloitte Canada domain (CA). Alternatively, any OU structure that allows for quick access to group and user location within the hierarchy can also be used to address ease of management.

The Site Owners (or Site Administrators) of any SharePoint site and specifically those in highly collaborative sites such as internal and external team sites, should be trained on how to properly permission content. The process used for securing content using Active Directory or SharePoint groups, depending on the situation, must be well understood by this user group.

In addition to proper training and processes, there are third party tools and tools that SharePoint 2010 out of the box for creating reports on how content is permissioned in SharePoint. The SharePoint feature to report on permissions is available through the Site Settings/Site Permissions/Check Permissions link. This feature cannot be used to report on content permissions across multiple sites. Therefore, third party tools may be more appropriate for more automated audit capabilities.

SharePoint 2010 also provides audit capabilities. The audit configuration can be setup at the site collection level or at the individual list or library level. The audit feature can be configured based on the following settings:

1. What actions to audit for documents and items:a. Opening or downloading documents, viewing items in lists, or viewing item

propertiesb. Editing itemsc. Checking out or checking in itemsd. Moving or copying items to another location in the sitee. Deleting or restoring items

2. What events to log for lists, libraries, and sites:a. Editing content types and columnsb. Searching site contentc. Editing users and permissions

Auditing the above events and actions across site collections could generate a large audit log. Although audit logs can be trimmed and removed from the SharePoint databases, it is recommended this feature is only enabled on sites, lists, or libraries that require it. The audit feature should not be used across any type of collaboration site.


000Deloitte Canada0

The table below lists the recommended limits for end user permissions in SharePoint 2010. These limits should be taken into consideration when designing an application that requires a lot of roles and responsibilities for many users.

Limit Maximum value

Limit Type

Notes

Number of SharePoint groups a User can belong to

5,000 Supported

This is not a hard limit but it is consistent with Active Directory® guidelines. There are several things that affect this number:

The size of the user token The groups cache: we have a table that

caches the number of groups an user belongs to as soon as those groups are user for in ACLs

The security check time: as the number of groups a user is a member of increases, the time required for access check increase as well.

Active Directory Principals/Users in a SharePoint group

5,000 per SharePoint group

Supported

SharePoint allows you add users or Active Directory groups to a SharePoint group.Having up to 5,000 users (or Active Directory groups or users) in a SharePoint group provides acceptable performance.The actions affected by this Limit are:a) Fetching user to validate permissions, this operation grows incrementally with growth in number of users in a group.b) Rendering the membership of the view will always require time.

Team Site Service – Internal and External

The Team Site service, both internal and external, should identify site owners. One of the responsibilities of the site owners should be management of access to the SharePoint sites. Site Administrators should only be allowed access to a team site once they have completed the appropriate training and passed a knowledge check test. This ensures access to team sites is not inadvertently being exposed to more users (and customers) than it should be. A process for

MySite

The individual site collections within My Site, by default, have both a Shared Documents library and a Private Documents library. These libraries have different permissions. If it is desired to share private documents, perhaps with a manager, the user should create a custom group (using People and Groups in Site Settings). Add the users to share the content with to the custom group and give the group the appropriate permissions to the library. Granting individual permissions to particular documents is permitted but should not be used as it is not a recommended practice. Setting up


000Deloitte Canada0

separate document libraries may be beneficial in this case as it eliminates the risk of individuals overwriting the current end users’ documents. This should be covered in a training module that users can refer to.

Often a user will want to create a personal Blog on their My Site. This is permitted. The blog is a sub-site, and should be given appropriate permissions so that the organization at large can participate, e.g. Read or Contribute.

Custom application permissions

Custom SharePoint 2010 solutions or applications must take into consideration the permissions available at the web application level where the custom solution or application is deployed to. Permissions are categorized based on the objects they apply to. There are three categories the permissions apply to: list, site, and personal permissions. It is also worth noting permissions have dependencies on each other. The details of the site, list, and personal permissions are available at the following site: http://technet.microsoft.com/en-us/library/cc721640.aspx.

Key Considerations

It’s important to call out who is responsible for permissions and permission management.

Example: The site owner is solely responsible for the team site and its permission management. Additional operations required by end users and that can only be executed by site collection administrators can be performed by the KMO team or the Helpdesk.

5.1.5 Asset Classification (Data Security)

Purpose

Understanding your data is critical to promote proper security, auditing, approval, and data protection.

In order to properly secure information, we must first be able to identify its information classification. (Asset classification has more uses than just securing data; it also improves discoverability and search relevance, as well as allowing for information management policies). There are many different information classification schemes. You can develop and implement a classification system for sites and content supported by your service that identifies the value of the information to your organization. Each of these classes may have its own policy for the storage, transmission, and disposal of information.

Defined By

Strategy Team, Architect (SP&E and Enterprise Architecture), Security Resource, KMO

Policy Definition

Deloitte Canada has a vocabulary already defined for the various asset classification levels. There is also flexibility, at the Service or department level to apply this taxonomy to any new content that may arise. For the internal team sites, end users and site owners must be made aware of the asset classification vocabulary and how content should be tagged and handled based on various scenarios.


http://technet.microsoft.com/en-us/library/cc721640.aspx

000Deloitte Canada0

Existing training materials already cover this topic and should be extended to the external team site owners.

Asset classification for external team sites will be included in the training material for all site owners. The asset classification for the external team sites will be easier to implement as all of the customer facing sites must be Deloitte and customer confidential.

Key Considerations

The new metadata services feature in SharePoint Server 2010 is an ideal way to implement asset classification through managed terms and enterprise-wide content types.

For self-service provisioning, when a site collection is created, make the asset classification selection mandatory. Provide a set of values to identify the content stored in a particular site collection. A sample asset classification description is included below for reference.

Area Policy

Information Ownership

All information has at least one owner, who is the site owner for the container for the information. Most documents also are owned by the person listed as document author. But if that person leaves the company, then the site owner is ultimately accountable.

Default Classification

All information is classified as confidential by default.

Information Access The owner is responsible for declaring who is allowed access to the information.

Information Security

The owner is responsible for securing the information or for seeing that it is properly secured by the administrator.

Content Appropriateness

The owner is responsible for adhering to OFI standards regarding offensive materials and appropriate use of company resources.

Public Class Available for distribution or publication outside of OFI.

Internal Class Generally means for company consumption only; but within company, is not sensitive.

Confidential Class Sensitive within the company, often to be further limited to department or team using security.

Restricted Class Material which contains Personally Identifiable Information (PII) such as credit card numbers, answers to secret questions,

Secret Class Should be protected using security and possibly Information Rights Mgmt. Secret documents typically entail strategic plans, internal audits or security matters, and the like.


000Deloitte Canada0

5.1.6 Lifecycle Management

Purpose

Uncontrolled proliferation of data and sites within SharePoint Server 2010 implementations can negatively impact the architecture plans. Without proper monitoring and governance policies, it is very difficult to manage large-scale implementations with hundreds of site collections.

It is important asset classification is implemented in conjunction with lifecycle management in order to automate processes based on content type for audit purposes.

In order to implement a process for lifecycle management, it is important a set of policies is defined for each service or solution deployed on SharePoint 2010. The services offered on SharePoint 2010 that have self-service provisioning available must provide a way for any site collection or site administrator to update lifecycle management information. The information collected will be used to implement specific processes for site retention and backup/restore SLA/SLO.

Defined By

Strategy Team, Architect (SP&E Enterprise Architecture), System Administrators (CAS), Security Resource, KMO

Policy Definition

Team Sites and External Team Sites

Site collections created using the team site template (including any custom features built, deployed, and activated by Deloitte Canada) will have three stages for content lifecycle.

Figure 8 Team Site Lifecycle


000Deloitte Canada0

Stage 1 runs throughout the initial site collection lifecycle – from the creation of the site collection to archival.

Stage 2 of a site collection starts at 1.5 years after its creation and once the site collection is placed in online archive.

Online archive will be activated 1.5 years after the site collection has been created. The entire site collection will be flagged for archival, including any sub-sites. The site collection administrator will be reminded about the site expiry 2 and 1 month prior to the 1.5 year mark. If no response is received, the site collection will be archived at the 1.5 year mark. The site administrators will have the following options:

1. Extend the site for another 1.5 years2. Request for the site to be archived at any time between the 1.3 and 1.5 year mark3. Do nothing – the site collection will automatically be archived at the 1.5 year mark.

Online archive will leave “stubs” behind for the archived content; this will offer end users a way to retrieve archived content if needed past the 1.5 year mark.

Stage 3 starts when the site collections stored in the online archive are moved to the offline archive and the site collection is deleted from the online archive. The offline archive requires site collection information (metadata) that was collected at site collection creation time in order to provide the Support and CAS teams an easy access method to site collections archived in Stage 3.

Stage 4 starts at the 7 year mark of the site collections’ lifecycle. At this point, the site collection is completely removed from the archives.

MySites

MySite site collections will be automatically created for all the Deloitte Canada employees. The MySite site collections should be archived and then deleted for any employees who leave Deloitte Canada.

Custom Applications or Solutions

Any custom application or solution that leverages SharePoint for storing content should have a lifecycle defined.

Key Considerations

Ensure inactive sites are archived and then retired by taking the content off of the SharePoint production farm(s).

You can implement a Windows Server Group Policy in order to block SharePoint Server 2010 installs. This is beneficial to control unintended usage and functionality within applications and sites or rogue deployments of SharePoint.

Deloitte Canada has a manual for policies and procedures for content retention. This document has started since Deloitte engagements had all documentation for customers in paper format. Furthermore, the policy manual contains addendums for each Service Line and department within


000Deloitte Canada0

Deloitte where the need to add to the original document existed. It is recommended that for each SharePoint site collection, custom application, and solution, the retention manual must be used to implement appropriate archiving policies.

5.1.7 Branding and Templates

Purpose

SharePoint Server 2010 includes several default templates. However, these often require some amount of customization to meet an organization or department’s needs.

When appropriately used, customization is vital and helpful, but it is also important to define standards across a large-scale deployment like the Deloitte Canada deployment.

A site template is a set of saved customizations on a site definition. You can choose which site templates to make available, especially for lower levels of your service. Templates can be configured so that the owner cannot substantially customize the site.

Use site templates to provide branding and other elements that identify the purpose of the site and associate it with the enterprise.

Defined By

Strategy Team, Architect (Collaborative Solutions Group), User Experience Manager, System Administrators (CAS), KMO

Policy Definition

Branding: two themes will be used for team sites (internal and external).

Custom applications must consider site templates and branding separately, based on individual needs. However, the Deloitte Canada branding guideline should be used for these applications as well.

Out of the box site definitions should be used for all of the site collections or sites at Deloitte. Out of the box site templates should be used as well. Any customizations required to the out of the box site templates can be repackaged as different site templates. Custom site definitions should not be used due to impact on future upgrades. Instead, features can be used to implement the customizations required. This type of customization must be developed and packaged using Visual Studio 2010.

Feature stapling is another method that allows customizations to be introduced for certain site templates when a site is implemented. The feature stapling attaches to the provisioning process in SharePoint and is specific to a pre-defined site template. Once the site template has been created, the feature receiver runs and makes the modifications or runs the operations required. Feature stapling code requires full trust deployment and impacts the whole farm.

Additional information feature stapling can be found at this location: http://msdn.microsoft.com/en-us/library/ms460318.aspx.


http://msdn.microsoft.com/en-us/library/ms460318.aspx


000Deloitte Canada0

Key Considerations

Different types of workloads require different site templates. For example, Internet presence and many enterprise-portal implementations require the publishing templates that come with SharePoint Server 2010. It is important to understand the underlying dependencies of template features and corresponding SharePoint Server 2010 workloads.

5.1.8 Data Protection

Purpose

Data protection is critical to an organization. A catastrophic event (for example, losing all data due to disk failure) can be devastating to your organization.

Data protection includes backup and recovery features and the design of redundant systems. You can vary the level of data protection you offer based on the service levels you provide. For each level of service, plan the frequency at which you will back up sites and the response time you will guarantee for restoring sites.

Defined By

System Administrators, SQL Administrators - CAS

Policy Definition

Recycle bin policy – default settings of 30 days for end user and another 30 days for site collection administrators.- 113 GB for content database size and 37 GB of Recycle Bin

Individual server backup completed by using Windows Server CommVault backup. The backup includes the SharePoint installation folders and files.

Daily full backup for both Windows server and SQL Server servers and databases. Restore SLAs to be determined Different SLAs for External Team Sites and content databases. Database mirroring for databases will be used in the SharePoint 2010 farm. For data corruption – transaction log backups will be used to rebuild the SharePoint

databases.

Key Considerations

No specific considerations.

5.1.9 Customization Policy

Purpose

SharePoint Server 2010 includes customizable features and capabilities across multiple product areas (like business intelligence, forms, workflow, and content management). However, customization introduces new risks to the stability, maintainability, and security of the SharePoint Server 2010 environment.

To support customization in a controlled manner, develop a customization policy that addresses the following:


000Deloitte Canada0

The customization tools that are allowed. The types of customizations supported. The method for handling source code (like how it will be maintained, use of a source control

system, and how it will be documented). Development standards (like coding best practices). Testing and verification standards. Required packaging and installing methods.

Defined By

Architects (SP&E Enterprise Architecture and Collaborative Solutions Group), Development Manager (Collaborative Solutions Group), Test Manager (Test Group), User Experience Manager (Collaborative Solutions Group), System Administrators (CAS), Security Resource

Policy Definition

The production environments will not have sandbox solutions feature activated.

SharePoint Designer 2010: use WSP to publish the customizations made through Designer. Development environment would be the first and last environment to allow SharePoint Designer 2010.

Visual Studio 2010: should be used in the Development and Development CA environments only. The customizations developed in Visual Studio 2010 should only be deployed using WSP (Windows SharePoint Packages) and PowerShell scripts. All of the customizations that can be implemented in Visual Studio 2010 can be deployed using this method. Any additional commands that need to run can be executed using either PowerShell or STSADM commands.

Environments: Dev., Dev. CA (new environment), QA (used as demo sometimes), UAT (sign off environment by customers), CA (Content Authoring), Production.

InstallShield: for deployment of SharePoint customizations specifically, as well as any related .NET code or assemblies, WSP packages along with PowerShell and STSADM commands can be used for deployment. All of the customizations deployed on a SharePoint server are automatically deployed to all the appropriate servers in the farm. Therefore, InstallShield is not recommended for SharePoint customizations deployments. Any additional, helper database or application should leverage the Deloitte Canada standard for packaging.

Visio 2010: should be used to model SharePoint workflows. The workflows created by Business Analysts or Power Users can be imported into SharePoint Designer for further development. Additionally, in the future, as users start using Visio for data modeling and integrate with SharePoint, Visio 2010 use may expand beyond Business Analysts and Power Users.

The following table lists the possible SharePoint customizations and the policies for implementing these customizations in the Deloitte Canada SharePoint 2010 environment:

Customization Allowed (Y/N) Additional CommentsManaged Path Y http://msdn.microsoft.com/en-us/

library/bb802766(v=office.12).aspx


http://msdn.microsoft.com/en-us/library/bb802766(v=office.12).aspx


000Deloitte Canada0

SharePoint Database Schema Change

N http://msdn.microsoft.com/en-us/library/bb862278(v=office.12).aspx

SharePoint Database Access N http://msdn.microsoft.com/en-us/library/bb861829(v=office.12).aspx

Modifying Built-In SharePoint Files

N http://msdn.microsoft.com/en-us/library/bb803457(v=office.12).aspx

Web Services Access Y http://msdn.microsoft.com/en-us/library/ee705814.aspx

SharePoint Designer Editing Y SharePoint designer access is only allowed in the development environment. All changes mu either be manually added to a WSP file in Visual Studio 2010 or a WSP file should be created right from SharePoint Designer 2010

SharePoint Solution Y http://msdn.microsoft.com/en-us/library/bb862721(v=office.12).aspx

SharePoint Feature Y http://msdn.microsoft.com/en-us/library/bb861828(v=office.12).aspx

Feature stapling Y http://msdn.microsoft.com/en-us/library/bb861862(v=office.12).aspx

Feature Event Receiver Y http://msdn.microsoft.com/en-us/library/bb862634(v=office.12).aspx

Windows Server Service Y http://msdn.microsoft.com/en-us/library/bb862915(v=office.12).aspx

Timer Job Y http://msdn.microsoft.com/en-us/library/bb862072(v=office.12).aspx

Web Application Y http://msdn.microsoft.com/en-us/library/bb862153(v=office.12).aspx

Web Service Y http://msdn.microsoft.com/en-us/library/bb862168(v=office.12).aspx

Site definition N http://msdn.microsoft.com/en-us/library/bb802774(v=office.12).aspxFeatures should be used instead to ensure upgrade and migration ease in the future.

List definition Y http://msdn.microsoft.com/en-us/library/bb862047(v=office.12).aspxList definitions should only be accepted as features and not within site definitions. This implementation approach is possible since Office SharePoint Server 2007.

Site Template Y http://msdn.microsoft.com/en-us/library/bb802960(v=office.12).aspxOnly allowed as a way to create “cookie-cutter” templates for use by multiple Services and Service lines. Should not be used as a backup method.
























http://msdn.microsoft.com/en-us/library/ee705814.aspx






000Deloitte Canada0

List template Y http://msdn.microsoft.com/en-us/library/bb802990(v=office.12).aspx

Field type Y http://msdn.microsoft.com/en-us/library/bb862128(v=office.12).aspx

Content type Y http://msdn.microsoft.com/en-us/library/bb802962(v=office.12).aspxShould be deployed using site or site collection features.

Column Template or Site Column

Y http://msdn.microsoft.com/en-us/library/bb861868(v=office.12).aspx

Delegate control Y http://msdn.microsoft.com/en-us/library/bb861966(v=office.12).aspx

Form template N http://msdn.microsoft.com/en-us/library/bb815164(v=office.12).aspxIn SharePoint 2010, with the help of InfoPath Forms Services, the form templates can be modified through InfoPath Designer 2010. This is the recommended approach for SharePoint 2010 implementations.

Custom Action Y http://msdn.microsoft.com/en-us/library/bb802874(v=office.12).aspx

_Layouts page Y http://msdn.microsoft.com/en-us/library/bb815343(v=office.12).aspx

Event handler Y http://msdn.microsoft.com/en-us/library/bb802822(v=office.12).aspx

Coded workflow Y http://msdn.microsoft.com/en-us/library/bb862230(v=office.12).aspx

No code workflow Y http://msdn.microsoft.com/en-us/library/bb862089(v=office.12).aspxNo code workflow should be developed, packaged, and deployed through the use of SharePoint Designer 2010.

Workflow activity Y http://msdn.microsoft.com/en-us/library/bb863182(v=office.12).aspx

Workflow condition Y http://msdn.microsoft.com/en-us/library/bb862100(v=office.12).aspx

Web part Y http://msdn.microsoft.com/en-us/sharepoint/ee513148.aspxVisual web part development is now available with Visual Studio 2010. Therefore, any type of development that is required around custom web parts should be done using this feature and Visual Studio 2010.

SharePoint theme Y http://msdn.microsoft.com/en-us/library/gg430141.aspx Branding for SharePoint 2010 page is different from SharePoint 2007. The above link is


http://msdn.microsoft.com/en-us/library/gg430141.aspx

http://msdn.microsoft.com/en-us/library/gg430141.aspx

http://msdn.microsoft.com/en-us/sharepoint/ee513148.aspx




















000Deloitte Canada0

recommended for review and use during not only implementation of branding but also during design phase to ensure the creative designers understand the components of a SharePoint 2010 page.

Document icon Y http://msdn.microsoft.com/en-us/library/bb861930(v=office.12).aspx

iFilter Y http://msdn.microsoft.com/en-us/library/bb861906(v=office.12).aspxiFilters are still required for indexing file types SharePoint doesn’t provide out-of-the-box functionality for. One such example, is the PDF iFilter for indexing the content of the PDF files. A pure 64 bit iFilter (opposed to a 32-bit iFilter wrapped in 64-bit code) is recommended for this functionality. Additional iFilters may be available and should be properly investigated.

Document converter Y http://msdn.microsoft.com/en-us/library/ms518493.aspx

Information Management Policy

Y http://msdn.microsoft.com/en-us/library/bb815286(v=office.12).aspx

Business Data Catalog application definition

Y http://msdn.microsoft.com/en-us/library/ee556390.aspxThe BDC feature has changed significantly enough between SharePoint Server 2007 and SharePoint Server 2010 that it is worth re-investigating any customizations based on this technology before migration.

Excel Services user-defined function

Y http://msdn.microsoft.com/en-us/library/ms493934.aspx

InfoPath form custom code Y http://msdn.microsoft.com/en-us/library/aa701145.aspx

InfoPath form view control Y http://msdn.microsoft.com/en-us/library/ms772110(v=office.12).aspx

HTTP Handler Y http://msdn.microsoft.com/en-us/library/bb862197(v=office.12).aspx

HTTP Module Y http://msdn.microsoft.com/en-us/library/bb862635(v=office.12).aspxShould be considered very carefully and should require extensive testing, including performance testing.

Pluggable authentication provider

Y http://msdn.microsoft.com/en-us/library/ms457529.aspx

Pluggable single sign-on provider

Y http://msdn.microsoft.com/en-us/library/ee557936(office.14).aspx


http://msdn.microsoft.com/en-us/library/ee557936(office.14).aspx

http://msdn.microsoft.com/en-us/library/ee557936(office.14).aspx











000Deloitte Canada0

The use of the Secure Store Service application is recommended for this type of task.

STSADM command extension

Y http://msdn.microsoft.com/en-us/library/bb417382.aspxShould be used for any type of operations-oriented task that must be scripted.

PowerShell cmdlets Y http://technet.microsoft.com/en-us/library/gg550867.aspx

Inline code N http://msdn.microsoft.com/en-us/library/bb862025(v=office.12).aspx

Web.config file settings change

Y http://msdn.microsoft.com/en-us/library/bb802890(v=office.12).aspxweb.config file setting changes should be implemented in situations where there is no other route or option for using SharePoint property bags or a common repository of settings. Any changes to web.config files not only must be manually made and tested against every single server in the SharePoint farm but also automatically initiate an application pool reset which has an impact on end-user experience.

Security policy Y http://msdn.microsoft.com/en-us/library/bb862636(v=office.12).aspxSecurity policies are required when custom .NET assemblies, such as custom web parts, required highed level access than the standard security policy allows. The implementation of such policies should be conducted together with EA and Security Architect to ensure proper implementation and eliminate any potential security risks, especially when it comes to deployment in the extranet zone of DOL or the External team sites.

Key Considerations

Prefer composite solutions over custom solutions. Composite solutions require little to no code to implement a specific customization and remove the need to write and compile code. It also shortens the test cycle as it focuses specifically on functionality testing.






http://msdn.microsoft.com/en-us/library/bb417382.aspx


000Deloitte Canada0

5.1.10 Site Templates

Purpose

SharePoint Server 2010 includes several default templates. However these often require some amount of customization to meet an organization or department’s needs.

When appropriately used, customization is vital and helpful, but it is also important to define standards across a large-scale deployment.

Site templates are a set of customizations applied to a site definition. By using a site template, a SharePoint Server service can promote consistent branding, site structure, and layout in the sites that users create. You can create customized site templates for provisioning sites and use them instead of the templates that are included in SharePoint Server 2010 as part of your SharePoint Server 2010 service.

Defined By

Architects (SP&E Enterprise Architecture and Collaborative Solutions Group), User Experience Manager (Collaborative Solutions Group), System Administrators (CAS), KMO

Policy Definition

Leverage the Team Site template along with all out of the box templates for all services and custom applications or solutions. Changes to any of the out of the box site templates should be implemented through features. New site templates should only be created if a certain site structure is required or customized document templates are required.

Key Considerations

Different types of workloads require different site templates. For example, Internet presence and many enterprise-portal implementations require the publishing templates that come with SharePoint Server 2010. It is important to understand the underlying dependencies of template features and corresponding SharePoint Server 2010 workloads.

5.1.11 Workflows

Purpose

Workflows are an essential component for document collaboration and content publishing and deployment, as well as custom solution development. There are many ways to support workflow configuration or development within SharePoint Server 2010 and the implications of any choice can have a large impact on the organization.

As mentioned in the Key Considerations column, many tools are available to customize SharePoint Server 2010. Consider the following before creating any workflows: Which ones will you use or support?

Will you build data entry forms with Microsoft Office InfoPath 2010 or Microsoft® ASP.NET? Will you leverage available workflows for publishing or write custom ones? How will custom workflows impact publishing?


000Deloitte Canada0

Workflows are software programs that implement business processes for users of a SharePoint Server 2010 site. They are associated with items in the site (like documents, forms, list items, or the site itself). Workflows have many applications as part of an IT service. For example, you can use a workflow to provision a new site, track a support issue, or take action when a site's quota is exceeded.

Defined By

Architects (SP&E Enterprise Architecture and Collaborative Solutions Group), Development Manager (Collaborative Solutions Group), System Administrators (CAS), Security Resource

Policy Definition

SharePoint Server 2010 out of the box workflows available to the end users are:

Collect Feedback Routes a document or item to a group of people for feedback. Reviewers can provide feedback, which is then compiled and sent to the person who initiated the workflow. By default, the Collect Feedback workflow is associated with the Document content type, and therefore it is automatically available in document libraries.

Approval Routes a document or item to a group of people for approval. By default, the Approval workflow is associated with the Document content type, and therefore it is automatically available in document libraries. A version of the Approval workflow is also associated by default with the Pages library on a publishing site, and can be used to manage the approval process for the publication of Web pages.

Disposition Approval Manages document expiration and retention by letting participants to decide whether to keep or delete expired documents. The Disposition Approval workflow supports record management processes and is intended for use primarily in a Records Center site.

Collect Signatures Routes a document that was created in a Microsoft application to a group of people to collect their digital signatures. This workflow must be started in applications in the 2007 Microsoft Office system and the Microsoft Office 2010 suites such as Microsoft Word. Participants must complete their signature tasks by adding their digital signatures to the documents in the relevant client program. By default, the Collect Signatures workflow is associated with the Document content type, and therefore is automatically available in document libraries. However, the Collect Signatures workflow appears for a document in the document library only if that document contains one or more Microsoft Office Signature Lines. For more information on Microsoft Office Signature Lines, see Add or remove a digital signature in Office documents (http://go.microsoft.com/fwlink/?LinkId=157408).

Three-state Designed to track the status of a list item through three states (phases). It can be used to manage business processes that require a high volume of issues or items, such as customer support issues, sales leads, or project tasks to be tracked. The Three-state workflow is so named because it tracks the status of an issue or item through three different states, and through two transitions between the states. For example, when a workflow is initiated on an issue in an Issues list, SharePoint Server 2010 creates a task for the assigned user. When the user completes the task, the workflow changes from its initial state (Active) to its middle state (Resolved) and creates a task for the assigned user. When the user


http://go.microsoft.com/fwlink/?LinkId=157408


000Deloitte Canada0

completes the task, the workflow changes from its middle state (Resolved) to its final state (Closed), and creates another task for the user to whom the workflow is assigned at that time. Note that this workflow is only supported on lists, not libraries.

Translation Management Manages manual document translation by creating copies of the document to be translated and by assigning translation tasks to translators. This workflow is available only for Translation Management libraries.

Issue Tracking Routes an issue to team members for resolution. It presents a Web page to the user who makes possible the entry of new issues; for example, customer complaints. As an issue progresses though different workflow states, the Web page of the user changes to reflect appropriate events; for example, a Web page that was closed when an issue is resolved.

Any of the out of the box workflows listed above can be customized based on the settings available in the workflow settings pages. For example, additional approval stages and approvers can be added to an Approval workflow. Any customizations that go beyond the base change or the messages’ text and description must be implemented through custom workflows in Visual Studio 2010. Additionally, the SDLC should be followed for these types of customizations.

Setting aside the Business Analyst tools for designing SharePoint workflows, there are two options Microsoft provides around development tools: SharePoint Designer and Workflow Designer in Visual Studio 2010. A comparison of the tools is provided at the following location: http://technet.microsoft.com/en-ca/library/cc263308.aspx.

As mentioned in Section 5.4.3 Workflow in the Architecture Roadmap document, there are four scenario types based on what SharePoint workflow was intended for:

Approval or feedback collection on documents If a SharePoint list (not a document library) is used to store the data then any type of

information that is collected in the list can be submitted to an approval process. The approval process can interact with external-to-SharePoint processes provided by external line of business systems.

A SharePoint list can be used as intermediary storage to update a backend system by integrating human workflow and a set of web services or APIs specific to that backend line of business application. In this case, the workflow implemented must take into consideration all of the business process monitoring that occurs or is required.

A SharePoint workflow can also take part in service bus architecture as a consumer of those services. However, it is important that SharePoint remains a human workflow tool that revolves around content stored in lists and document libraries and only consumes from those enterprise services.

Key Considerations

SharePoint Server 2010 supports out-of-the-box workflows as well as custom workflows with Microsoft SharePoint Designer 2010, Microsoft Visual Studio® 2010, and Windows® Workflow Foundation. The types of workflow implementations that are supported across groups should be stipulated in the governance plan.


http://technet.microsoft.com/en-ca/library/cc263308.aspx

000Deloitte Canada0

Note

Although developing workflows with Windows Workflow Foundation creates more advanced and powerful workflows, it often involves a steep learning curve and can be an expensive investment in terms of the time needed to build, test, and deploy such workflows.

Additional information on appropriate use of workflow tools and the target SharePoint technology can be found at http://msdn.microsoft.com/en-us/library/ms461944.aspx.

5.1.12 Sandboxing

Purpose

Sandboxing allow individual Service Lines to write and deploy code to their own SharePoint sites. The sandbox solutions cannot take advantage of all the SharePoint APIs and are limited to the object model that can be monitored.

Defined By

Strategy team, Architects (SP&E Enterprise Architecture and Collaborative Solutions Group), Development Manager (Collaborative Solutions Group), Test Manager (Test Group), System Administrators (CAS), Security Resource

Policy Definition

Sandboxing will not be allowed in the Deloitte Canada SharePoint 2010 environments. The only environment that will allow sandbox solution deployment will be the development environment provisioned for the Deloitte Canada Consulting service line for developing and testing customer engagements’ code and customizations.

Key Considerations

LimitationsSandboxed solutions cannot use certain computer and network resources and cannot access content outside the site collection they are deployed inside. If you need to access to content external to the site collection, you need to use a full-trust proxy or use Microsoft Business Connectivity Services to perform the content access on behalf of the sandboxed solution.

TrainingSandboxed solutions delegates (or offloads) the support challenges to others within the organization. Depending on the type of solution, site-collection administrators or users who have been granted full-control permissions at the root of the site collection can deploy the solution. While this may remove a burden from operations and provide convenience to site-collection users, it also presents a new layer of delegation for SharePoint, which has historically been challenging for many organizations to absorb.

Users who deploy sandboxed solutions will undoubtedly need to help troubleshoot issues with sandboxed deployments.


000Deloitte Canada0

Site-collection users with deployment permissions need to be educated (or at least cautioned) about what types of solutions are appropriate for deployment.

SupportSandboxed solutions will require the same support and troubleshooting attention as farm-deployed solutions. The question to consider before deploying a sandboxed solution is to determine who will be responsible for supporting issues that are caused by sandboxed solutions.

PerformanceArchitecting the sandboxed solution environment for throttling, load balancing, and a dedicated server are important considerations. However, it is also important to understand the culture within the organization. It is hard to architect a proper environment if you do not have a solid grasp of the numbers and types of solutions that will be deployed over time. Throttling and load balancing are great mechanisms but are not “cure all” configurations. A sandboxed environment can be overloaded quite easily if controls are not put in place from an organizational perspective to limit and control the types of solutions that are deployed.

5.1.13 Records Management

Purpose

A record is a document or other electronic or physical entity in an organization that serves as evidence of an activity or transaction performed by the organization.

Records require retention for some time period to meet legal, business, or regulatory requirements.

Records management is the process by which an organization determines what types of information should be considered as records, how records should be managed while they are active, and for how long each type of record should be retained.

Deloitte Canada has selected OpenText Content Server as the technology for Records Management. With the integration provided between OpenText Content Server and SharePoint 2010, the policy at Deloitte Canada is to leverage content types and document libraries to turn a SharePoint document into a record. Once the record has been received by Content Server’s enterprise library, the document will no longer be available in the SharePoint document libraries for end users to collaborate on. The OpenText Content Server integration will allow for a stub to be left behind so that end users can still access the archived document, if required.

Defined By

Strategy team, Architects (SP&E Enterprise Architecture and Collaborative Solutions Group), System Administrators (CAS), Security Resource

Policy Definition

Processes to be defined: for both content type based and ad-hoc. All of the policies for these types of records must be outlined. Moreover, proper processes and proper training should be provided to end users to allow for ease decisions on what documents should be identified as records and integrated into OpenText Content Server.


000Deloitte Canada0

The current Deloitte Canada collaboration/archiving process allow for minor versions to exist in SharePoint. All published/major versions will move to OpenText. This policy applies to documents that are identified as records. Any subsequent work done on the major/published versions will be completed in SharePoint and then moved to OpenText, once published. This process will create multiple minor versions (per major version) in the SharePoint document libraries.

Additional information will be included in this section once the OpenText integration is implemented.

Key Considerations

It is recommended a process to identify records and proper training is provided to all end users in order to fully take advantage of the RM system to be deployed.

5.1.14 Metadata Services

Purpose

Metadata services provide the capability to implement important facets of an information architecture plan.

The desired outcome of implementing metadata services typically includes:

More consistent classification of content. An official process to define and maintain taxonomy within and across site collections. Improved discoverability through site filters and Search.

You must define your information architecture and corresponding governance to achieve these outcomes.

Governance of the metadata services is implemented through:

The SharePoint Server 2010 farm. Planning should include how many term stores are necessary, what is the size of the term store, where term stores are physically located, who can manage aspects of the term store, and how terms are used within the site.

Information architecture. Information architecture planning helps define the number of term stores, the taxonomy structure, the size of the term store, the languages that need to be supported, and how terms map to content types and end user artefacts.

Defined By

Strategy team, Architects (SP&E Enterprise Architecture and Collaborative Solutions Group), System Administrators (CAS), Security Resource, KMO

Policy Definition

Synaptica is the tool used to manage Managed Metadata Services. Local customizations may be allowed, in the future, where certain users will be given access permissions to suggest terms, term sets, or keywords.

Synaptica is used by the KMO team to implement and deploy the taxonomy, keywords, synonyms, and all other related items. This will remain the policy with the deployment of SharePoint 2010.


000Deloitte Canada0

Through the Application Governance and Archiving (AGA) for Microsoft SharePoint add-on, OpenText’s Content Server integrates with SharePoint 2010 document libraries for both records management as well as archiving purposes. One of the options the AGA provides for identifying records or archiving content is to leverage content types. The content types, as defined in SharePoint through the out-of-the-box features or from Synaptica, can be used to identify content that must be archived or setup as a record. This configuration should occur when document libraries are configured. End users should be trained on what is the most effective way to attach to such a content type, especially in records management requirements.

Additional information will be provided once the OpenText Content Server has been rolled out and integrated with the SharePoint 2010 environment.

At the time of this document’s writing, a request has been made to use the built-in features of SharePoint to allow end users to submit suggestions into term sets managed by the Managed Metadata Services. The current process requires end users to submit folksonomies (term sets) suggestions into Synaptica through the KMO team or the service owners who oversee this service. SharePoint 2010 provides all of the tools and features to allow for end users to submit suggestions for terms in term sets (folksonomies), those suggestions to the reviewed and approved by a central team, such as the KMO team, and to integrate the suggestions into the service that everyone in Deloitte Canada can use. In order to take full advantage of the SharePoint platform and all of its benefits, it is recommended this approach be investigated and offered to Deloitte Canada employees.

Note

Any term suggestions into the Deloitte Canada Managed Metadata Service will only be visible at the Deloitte Canada level. For a term to appear in the global term sets, Synaptica use is still required.

For Managed Metadata Services (MMS) for external facing team sites, it is recommended either part of the internal MMS or full capabilities are deployed. Through the use of Synaptica and the custom developed tool for publishing to SharePoint 2010’s MMS service application, the content types, term sets, and keywords can be pushed to any other environment, separate from the central one.

The external team sites or any customer facing environment should have a stricter policy for allowing the submission of terms into the term sets. The submission should be controlled, either through a team like KMO or through a process that allows close monitoring of the terms and keywords submitted.

Key Considerations

PrivacyPrivacy is a key boundary that helps define the need for additional managed metadata services. For example, if the legal department term store contains confidential information that no one outside the department should view, having a separate managed metadata service is a plausible scenario.


000Deloitte Canada0

Metadata SharingUnderstanding the sharing requirements (or possibilities) across the organization is a key consideration for architecture. Sharing, along with information architecture and privacy, helps define a holistic view for how data should be maintained, shared, or isolated in the organization.

PerformanceTerm stores are stored in SQL Server databases. Understanding the size of the term stores is helpful for architecting the SQL Server deployment (like the location of database files across disks or separating databases across servers).

MaintainabilityIn multimanaged metadata service deployments, you can specify where keywords and column-specific data are stored with the default keyword location and default column-specific term set location attributes. Capturing terms in the proper term sets is important for completeness of your metadata.

ExtensibilityThe managed metadata platform supports a flexible and extensible model. However, organic growth of terms over time is not always extensible by nature. Organic growth has the potential to produce a taxonomy that differs significantly from what was defined in the planning phase. Through organic growth, users will add data undefined by the taxonomy, which creates a "folksonomy."

If the taxonomy for the metadata is not correctly defined during information-architecture planning, it can lead to structural problems in the term store. In these cases, a need for term store consolidation or restructuring can be very expensive after the fact.

5.1.15 Fluid Application Model

Purpose

A department or business unit may want to leverage data that is external to SharePoint Server 2010. This type of data is not the traditional line of business database data, but instead services that may reside internally or externally that can be easily consumed by SharePoint Server 2010 Web pages.

SharePoint Foundation 2010 introduces the Fluid Application Model to make this scenario possible in a secure way. The Fluid Application Model enables administrators to control the permissions of the external applications without unduly restricting the ability of users to add Web Parts hosting these applications to Web Part pages.

Defined By

Strategy team, Architects (SP&E Enterprise Architecture and Collaborative Solutions Group), System Administrators (CAS), Security Resource

Policy Definition

Policies should be created for exposing internal data to external or internal web properties. Access to line of business data like the one required for the fluid application model must go through proper security review.


000Deloitte Canada0

The security group must be involved in any decision to expose line of business data in a SharePoint site. It must be done on a request-by-request basis. All requests must be processed through this cycle. In the case where multiple requests for a similar service or line of business application to be exposed to internal SharePoint sites is required then a standard definition should be created and a policy must be defined to the use of the service. For example, if a line of business application provides a web service that can be consumed by multiple SharePoint sites, access to the interfaces should be maintained by the Security Group.

Additional information on use of web services for access to mainstream line of business applications within the Deloitte Canada environment will be further defined through a SOA governance model.

Key Considerations

PerformanceExternal systems are great for quickly creating mashups. However, external systems can cause performance issues through latency.

SecurityExternal systems raise security questions such as:

What types of data are being transmitted? Is the data transmitted securely? Does the service expose vulnerabilities to script attacks or other common Web threats? What sites are supported?

Supporting external systems from partners or the Internet requires an additional level of evaluation. From an organizational perspective, it is important to define what types of external systems are supported.

5.1.16 External lists

Purpose

External lists simplify visibility, accessibility, and maintainability of external content throughout the organization.

Conversely, an uncontrolled environment will possibly allow for access to external content in undesirable ways.

Limiting SharePoint Designer 2010 access and limiting security permissions are the primary means to control proliferation of external lists.

Training is important to educate users or department stakeholders of what is supported and what is not supported within the farm and department site collections.

Enforcing corporate list throttling rules to minimize performance impact to the SharePoint Server 2010 environment and to the external systems is necessary to minimize performance degradation or downtime.


000Deloitte Canada0

Defined By

Architects (SP&E Enterprise Architecture and Collaborative Solutions Group), System Administrators (CAS), Security Resource

Policy Definition

Undergo security assessment for these types of requests. This policy follows the same process as Fluid Application Model described in the section above..

It is important to investigate and define a checklist for the type of operations (as part of CRUD) that security can go through to review requests. Any such request should be tracked by the Security Group. The SharePoint platform, specifically the Business Data Catalogue application definitions, can be used to keep track all of the web services available in the environment and their descriptions such as operations allowed, authentication and authorization employed, etc.

The policy recommends implementing unit testing measures or metrics for building External Lists. The test group and more importantly, the Operations team (CAS) must validate any external interfaces exposed through SharePoint do not have a negative performance impact and end user experience.

Key Considerations

SecurityThere is a potential for external data to become editable in unintended ways. Limiting external list capabilities and managing permissions to the list are critical to maintain data integrity in the environment. Item-level permissions cannot be set on items in external lists.

PerformanceThere are many ways that performance can quickly become a problem with external lists. For example, if a number of tables or views from a single database or a single SQL Server are exposed within SharePoint Server 2010, the potential bandwidth exposure to the server has not been increased. If multiple users are viewing, filtering, and editing at the same time, the additional load may overload database servers that were never intended to support this additional entry point into the system.

Data ModificationForms that are derived from external data sources may not have the necessary business logic. In many cases, referential integrity is not enforced directly within the schema. These business rules are often enforced through stored procedures, Web services, or client applications. If the SharePoint Server 2010 external list form does not support the same business rules, data errors are likely to occur.

Versioning cannot be configured on items in external lists. Item history is not available.

SearchShould a search crawler be allowed to crawl external lists? Depending on the organization, this might be decided at the list, site, or organizational level.


000Deloitte Canada0

WorkflowsWorkflows cannot be configured on external lists.

5.1.17 Microsoft Business Data Connectivity (BDC)

Purpose

The Business Data Connectivity (BDC) service is a shared service in Office SharePoint Server 2007 that uses the SharePoint Server 2010 shared services architecture.

However, in SharePoint Server 2010, services are no longer contained within a Shared Services Provider (SSP) as they were in Office SharePoint Server 2007. The configuration of services is more flexible with BCS. Individual services can be configured independently by different sets of administrators. Multiple instances of the same service, (like the BDC) can run on the same farm, each with a unique set of administrators.

An instance of the BDC service can be shared across server farms. For example, a BDC service can be run in a central farm and accessed from regional locations so that the same solution is available across these locales.

Shared services (like the BDC) can each be administered in isolation. The administrators of a particular instance of a shared service may only have permissions to administer that service instance and are not necessarily able to administer other services or other features in the SharePoint Server 2010 Central Administration Web site.

This feature, called delegated administration, allows administration to be managed by administrators who have expertise in the particular service being administered, but who are not members of the central IT organization. For example, an administrator of a BDC service application in an enterprise might be familiar with the following information:

The particular external content types being managed by that BDC service application. The solutions supported by it. The security implemented on the external data sources that provide the data.

Defined By

Architects (SP&E Enterprise Architecture and Collaborative Solutions Group), System Administrators (CAS), Security Resource

Policy Definition

BDC locally (on the Deloitte Canada SharePoint farms) should be leveraged by SharePoint internal sites only. All of the external line of business application data to be exposed in SharePoint sites – for search, external lists, or custom web parts – should be published through the BDC first. If and only if web services or relational database management system interfaces do not exist for these line of business applications then web services should be developed to provide the functionality required. The web service development and publishing should be conducted as a separate task, separate from SharePoint consumption, and must consider all of the current and possible, future applications to use the interaction and data.


000Deloitte Canada0

DTTL (DOL) BDC use must still be approved by the security group prior to use in the environment. The interfaces and BDC application definitions provided by DTTL may not adhere to the standards and governance policies of Deloitte Canada.

Key Considerations

With new flexibility and capabilities, more governance is necessary to guide how the BCS feature is implemented.

Farm ArchitectureIs BCS used within a single farm or across multiple farms?

Line-of-Business (LOB) IntegrationBCS is a powerful capability that supports bringing external data into SharePoint Server 2010 in a structured manner. From an architectural perspective, governance should help guide how external data is leveraged in SharePoint Server 2010. With the new cross-farm sharing model, BCS connections should be defined and operated with the enterprise in mind instead of individual applications.

External Content TypesAre external content types deployed to production using SharePoint Designer 2010 or Windows SharePoint Services Solution Package (.wsp) files?

PermissionsWhat types of permissions do you give SharePoint Designer 2010 users in production?

5.1.18 Language Support

Purpose

Multilingual-based solutions often require the following:

Manage content in different languages. Navigate an Internet site or a corporate portal in a preferred language. Collaborate with people in different regions in different languages from within the same

application. Manage and administer personal sites by using a preferred language. Search and browse content across a company by using a preferred language.

Providing multiple languages in your SharePoint deployment can be very challenging. These implementations require implementing multiple SharePoint capabilities (like multilingual and variations) and can impact content deployment, search, term stores, site navigation, and custom Web Parts.

You should prepare for this functionality at the beginning of the project. Adding language support in later versions may seem like a good way to control scope. However, you will likely run into many challenges (including reworking your solutions and implementations) if you choose to implement language support in the later phases.

Language support is largely supported through two capabilities in SharePoint Server 2010:


000Deloitte Canada0

Multilingual Variations

Multilingual provides the foundational capabilities for multiple language sites. These capabilities are supported through language packs that you install on each SharePoint server.

Variations support the process of creating label hierarchies to create mirror copies of pages and content to support multiple languages.

Note: Exact mirrors are not required. Variations supports the process of creating and publishing the language-specific content, making it available to content deployment if it has been implemented in the solution.

Multilanguage sites require the following capabilities that are supported by multilingual and variations features:

Workflow capabilities, which allow for translation processes to be added to sites. Redirecting users to specific sites based on their language preferences. Hosting different sites in different languages or locales within the same site collection. Full Unicode support, so that users can create text (like titles, column names, and column

values) in different languages. Different documents in different languages can be stored in the same document library.

Information architecture considerations include:

Content types should be designed to support different language needs. Support for language-specific term store tagging. Variations labels and hierarchies should be constructed in a manner to support content

deployment, search, navigation, and term store usage. Support for Search feature components (like word breakers, stemming, noise words

dictionaries, and scopes). How Search processes language-specific queries and how results are filtered are essential to the overall end-user experience.

Site navigation links to the current site's peer sites are automatically generated in SharePoint Server 2010. You might not want this in a variations deployment. You need to determine what users should see.

Defined By

Architects (SP&E Enterprise Architecture and Collaborative Solutions Group), System Administrators (CAS)

Policy Definition

The use of the MUI or Variations capabilities will depend on the requirements of the service or custom application/solution.

The Deloitte Canada SharePoint 2010 environments will allow the use of both MUI and variations. It is recommended a more detailed analysis is done, case-by-case, to ensure the proper technology is used. In order to determine the use of MUI versus variations, the following table is provided for guidance. This table is also available in the SharePoint 2010 Architecture Roadmap document.


000Deloitte Canada0

Requirement Recommendation

Same content localized to different languages WCM sites with Variations

Country sites with own localized content WCM Sites

Same content targetted to specific devices WCM sites with Variations

Same content with different branding WCM sites with Variations

Localized collaboration SharePoint sites with Language Packs & MUI

Alternate languages SharePoint sites (MUI)

Key Considerations

Multilanguage sites require extensive planning well beyond the implementations of multilingual and variations capabilities. You need to consider the impacts across all functional and nonfunctional requirements to make sure that the solutions function properly.

This affects things like end-user experiences, IT support, publishing of variations content, viewing the SharePoint chrome using multilingual capabilities, and performance of the Content Deployment feature.

5.1.19 Publishing

Purpose

Publishing is the process of deploying branding artifacts, content, custom assemblies, and configuration files across a SharePoint Server 2010 farm. There are many factors to consider within these areas. For example, publishing content requires an in-depth analysis of the authoring tools, governance restrictions, and workflow approval processes.

Authoring content consists of creating content pages, editing data, publishing data, and approving data through out-of-the-box or custom workflows. The content authoring environment may consist of SharePoint user interface (UI), 2010 Microsoft® Office client applications (like Microsoft® Word 2010, Microsoft® Excel® 2010, and Microsoft® Visio® 2010), custom editing tools, and document converters.


000Deloitte Canada0

You can support most publishing requirements with SharePoint's out-of-the-box support for check in, check out, versioning, publishing, and approval workflows for content and pages.

Deployment is a requirement that describes how custom features are deployed (for example, how content is propagated and updated in the production environment and publishing schedules). The actual approach taken is influenced by security, performance, financial constraints, and complexity of the overall solution (how much customization is required for the solution).

Security has an impact on all phases of publishing (for example, who can edit content, who can approve content, and where is content authored (staging or production).

Defined By

Strategy Team, Architects (SP&E Enterprise Architecture and Collaborative Solutions Group), System Administrators (CAS), User Experience Manager (Collaborative Solutions Group), Development Manager (Collaborative Solutions Group), Test Manager (Test Group)

Policy Definition

Content Publishing should be used in the Content Authoring (CA) environment for publishing the content from CA to the UAT Production environments. Furthermore, any future web content management applications or solutions should leverage this functionality in order to push published or approved content from an internal farm to an external web presence. For example, if Deloitte Canada were to deploy SharePoint 2010 in the extranet environments for the deloitte.ca web presence then content publishing can be used to ensure there is segregation between the internal publishing environment and the Internet site.

Key Considerations

Not applicable.

5.1.20 Audit and content cleansing

Purpose

SharePoint Server 2010 includes audit features that can be used by Site Collection administrators or site owners/administrators. The audit features are configured to generate audit log entries based on the selected events and activities. The audit log can be used to report on list, library, and site activities.

The audit logs generated by the activities and events tracked can be trimmed. This is an option that site collection administrators have. Alternatively, site or service administrators can execute this task.

SharePoint 2010 does not provide any content cleansing tools. Additional software package would be required to achieve this functionality. Microsoft Forefront Protection 2010 for SharePoint, in addition to its anti-virus capabilities, allows SharePoint administrators (such as CAS) to prevent the upload or download of out-of-policy content with keyword filtering.

Defined By

Strategy Team, CAS, KMO, future service ownersPage 53

SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 0.4 FinalPrepared by [email protected]"document.docx" last modified on 25 Jul. 12, Rev 2

000Deloitte Canada0

Policy Definition

Native SharePoint audit feature should be used at the list or library level only for collaboration type service offerings such as Internal and External team sites. The reason for this recommendation is to minimize the impact of audit logs on the storage and minimize the consumption. A business reason must be provided for the audit feature to be used. Moreover, a time period should be configured to hold the audit logs online. The time period should not be longer than one week and the audit log should be backed up and taken offline the SharePoint databases.

Content cleansing with third party tools can be configured to run in real-time or on a scheduled basis. If a content cleansing/anti-virus combined tool is used, it is recommended the process is implemented on a schedule rather than real-time. When operating in real-time, during peak times, performance of the system may suffer.

Key Considerations

The audit process writes 1-2 entries per activity or event tracked. Each entry is approximately 2 Kilobytes (KBs) in size. Therefore, each activity or event tracked will generate 4 Kilobytes (KBs) of data, in the content database, per user per activity/event.

Content cleansing should target specific content and SharePoint sites. For example, content that is uploaded to a portal site like Gateway or O&E does not require cleansing as the publishing process is controlled.

5.1.21 Document Versioning

Purpose

SharePoint Server 2010 provides document versioning for document or form libraries. Document versioning can be configured to use major and minor versions. Moreover, a site administrator also has the option to control the number of major versions and minor versions to keep online, in SharePoint.

It is important to fully understand the configuration options for document versioning as they all impact the storage used by SharePoint.

Defined By

Strategy Team, CAS, KMO, future service owners

Policy Definition

Major and minor versioning should only be used in scenarios where there is a group of content authors who requires to work on the next version of a page or document while another version is visible to readers. Additionally, in order to identify a document that can be moved to records management system like OpenText’s Content Server, minor versions can be used as well.

Major versions should be used when there is a need to quickly create multiple versions of documents. By leveraging the check-in/check-out functionality, end users can create versions. Using the publishing action in document libraries that have both major and minor versions enable will allow for the creating of major versions from a minor version.


000Deloitte Canada0

When configuring versioning, there are two settings that allow for control of the storage used:

1. The number of major versions to keep2. The number of draft versions (minimum versions) to keep for the major versions defined in

point 1.

Document versioning should be considered as one of the backup strategies for documents. However, at the same time, it is recommended the number of versions to be kept online, in SharePoint, is limited to a certain number. For example, collaboration sites such as internal and external team sites should keep the number of versions to 5. This will ensure enough document versions are available before a backup is taken. Additional document versions can be configured based on business requirements.

Key Considerations

It is worth to note that document versions remain the same as in SharePoint Server 2007 in terms of configuration settings and impact on the infrastructure. Each version contains the full document. One new feature that has been added to SharePoint 2010 when used in conjunction with Office 2010, is the ability for multiple users to modify different sections of the same document, at the same time. This operation would not require users to check-in/check-out documents. Although this may seem like it has no impact on document versioning, there is no need to generate multiple versions when users can work on the same document at the same time. Hence, it eliminates the need to configure more document versions than required.

5.2 Development, Deployment, and Support Governance PoliciesDevelopment processes and guidelines should be defined for any development group. SharePoint projects are no different. Microsoft published a document called Team-Based Development in Microsoft Office SharePoint Server 2007. While this is a good starting place, many additional details of team-based development for SharePoint for customer use must be decided.

You must develop guidelines for the following aspects to define all the required development processes.

Application management – How are the files implementing an application organized and managed?

Source control – How can the application files be managed in source control? Build process – What procedures are used to build the system on the integration server? Deployment Process – What processes are used to deploy the system to the integration

server and then towards the production environment? Developer synchronization – How can developers be sure they are using the correct version

of all application files?




000Deloitte Canada0

5.2.1 Development Environment

Purpose

The development environments that are used for SharePoint custom application development should allow the complete set of resources that developers will need to create these new applications. These development environments should be autonomous and should allow the developer to work independently on his/her component without interfering with other developers. The unit testing should also be conducted within the developer’s individual environment.

The VMWare virtualized environment at Deloitte is an ideal way to standardize and scale the creation of development environments.

Development environments should include the following at a minimum:

Windows Server 2008 64 bit SQL Server 2008 64 bit (dedicated, local/shared/dedicated instance) SharePoint Server 2010 SharePoint Designer 2010 Visual Studio 2010

Defined By

Development Manager (Collaborative Solutions Group), System Administrators (CAS)

Policy Definition

Make a different between IDE and the Development VM – IDE is the integrated development environment where all of the code integration happens.

Central SQL Servers used for development. No separate instances allocated to development. (Dealing with multiple instances per developer VM is an administration challenge).

Note

It is recommended that SQL Server instances are implemented for the shared SQL Server farm used by the development environments. This approach, although it may introduce additional administration tasks for DBAs, makes it easier to control the namespaces of the SharePoint databases as well as storage lifecycle for the SQL Server.

Production Active Directory accounts are used by developers on their individual development environments to install, to configure, and to run the SharePoint 2010 installations. Moreover, these accounts are also used for access to the shared SQL Server farm where the development SharePoint databases are deployed.

In order to minimize the impact to the shared SQL Server environment, the developer accounts should be assigned the following permissions for the initial install of SharePoint server 2010:

Setup user The Setup user account is Domain user account.


000Deloitte Canada0

account used to run the following:

Setup

SharePoint Products Configuration Wizard

Member of the Administrators group on each server on which Setup is run.

SQL Server login on the computer that runs SQL Server.

Member of the following SQL Server security roles:

securityadmin fixed server role

dbcreator fixed server role

If you run Windows PowerShell cmdlets that affect a database, this account must be a member of the db_owner fixed database role for the database.

Server farm account or database access account

The server farm account is used to perform the following tasks:

Configure and manage the server farm.

Act as the application pool identity for the SharePoint Central Administration Web site.

Run the Microsoft SharePoint Foundation Workflow Timer Service.

Domain user account.

Additional permissions are automatically granted for the server farm account on Web servers and application servers that are joined to a server farm.The server farm account is automatically added as a SQL Server login on the computer that runs SQL Server. The account is added to the following SQL Server security roles:

dbcreator fixed server role

securityadmin fixed server role

db_owner fixed database role for all SharePoint databases in the server farm

Once the deployment and configuration has been setup, all of the server roles should be removed for the developers’ AD accounts. Ultimately, the db_owner fixed database role for all the SharePoint databases in the server farm are the only permissions required for proper operation of the development environments and for additional scripting work that is required by the developers.

Key Considerations

Customer may choose to use third party software to meet their specific needs if Visual Studio 2010 or SharePoint Designer do not meet their needs for custom application development on SharePoint.

Note: These products are not supported by Microsoft, and the customer should understand the consequences of using third-party applications.


000Deloitte Canada0

5.2.2 Design Goals

Purpose

The primary goal when designing “how to implement requirements” is to use "out-of-box" functionality whenever possible and to consider custom development only when necessary and justified. That said, "out-of-box" functions usually entail some level of effort that’s often overlooked in planning.

How you package and deploy "out-of-box" features from dev to test to production is an additional factor. While you can simply configure features and functionality through the SharePoint UI you need a way to version control configuration, and a scalable way to build and deploy configurations across environments.

Defined By

Development Manager (Collaborative Solutions Group)

Policy Definition

Any set of business requirements reviewed by business analysts and solution architects as targeting the SharePoint platform should take into consideration the out of the box features that SharePoint provides. All out of the box features should be considered and the level of development required should be minimal. In fact, the main design goal should always be: can we build the solution for the business requirements based on all the SharePoint feature and SharePoint tools we have in place? If a solution must target any kind of development then the complexity of the solution based on the SharePoint platform should be reviewed and carefully considered.

Customizations implemented using tools such as SharePoint Designer 2010 should be considered as they do not require custom, compiled code.

Custom applications and solutions that are targeting the SharePoint platform should use at least 75% or three quarters of the built-in SharePoint features. This does not imply that the solutions should only contain 25% code development and 75% out of the box functionality. The analysis should focus on whether all of the underlying SharePoint features, such as lists and how lists can handle data and data relationships, can be used effectively for the solution or custom application in question.

The recommended end to end design process of a SharePoint-based solution or application is described in details in the Architecture Roadmap document. The tools Deloitte Canada uses for design should be integrated with the version and source control systems in order to have a centralized location for storing solution and application artefacts.

Key Considerations

Ensure all of the business requirements can leverage one or more SharePoint capabilities or features and these are available in the Deloitte Canada environment.


000Deloitte Canada0

5.2.3 Development Process

Purpose

The overall development process defines how the team checks in source code, builds binaries, deploys solutions, tracks and fixes bugs, and where and how these processes occur.

The development process impacts developers, testers, operations, and ultimately end users. Clearly defining the development process is essential to ensure that incorrect assumptions are eliminated.

An example development process includes:

Developers and architects use development environments to develop application Code managed through source control, configuration and process Management tools like

Team Foundation Server Testing is performed in the test environment User acceptance testing performed in the user acceptance test environment Code is deployed into production environment after user acceptance testing

Defined By

Development Manager (Collaborative Solutions Group)

Policy Definition

Refer to the Deloitte Canada SDLC for SharePoint here.

TFS integration with all of the tools used at Deloitte: Rational Composer, TFS 2010, HP Quality Center (bug tracking) should be implemented in order to leverage the existing tools and the policies and procedures implemented for the software development lifecycle (SDLC).

As mentioned in the Architecture Roadmap documents, the lifecycle for SharePoint 2010 development should follow the process mapped out in the diagram below. Please refer to section 8.1 in the Architecture Roadmap document.


000Deloitte Canada0

Figure 9 SharePoint Server 2010 ALM

Key Considerations

As is the case with typical development projects, the developers of the solution must have full access to a development environment. The development environment must not be shared with other developers or by other projects in order to minimize the changes introduced through code and to allow for proper unit testing.

Once the developers complete the code on their individual Virtual Machines, the code should be uploaded to TFS 2010. The code should then be compiled and one or more package (WSP) files along with the required STSADM and PowerShell scripts, be installed and deployed in the Development Integration environment. The development integration environment should only have access to compiled packages and no code should be deployed using the Visual Studio 2010 IDE or SharePoint Designer 2010.

5.2.4 Versioning and Source Control

Purpose

Choosing a versioning product that integrates directly with Visual Studio is important, if not a requirement. This provides a more efficient environment, and helps enforce governance of source code management.

Visual Studio Team System provides source control that integrates with the development environment, and integrates with Team Foundation Server. Developers should be able to check-in, check-out and synchronize code files directly from their Visual Studio development environment.


000Deloitte Canada0

Defined By

Development Manager (Collaborative Solutions Group), Test Manager (Test Group)

Policy Definition

TFS 2010 should be used for versioning and source control. Access to TFS 2010 from Development VMs is mandatory.

In addition to using Team Foundation Server (TFS) 2010, a build process can be implemented for compiling customizations and building proper packages. For additional information on how to implement such a build process using TFS 2010 please refer to the following article: http://blogs.msdn.com/b/sharepointdev/archive/2011/08/25/creating-your-first-tfs-build-process-for-sharepoint-projects.aspx.

The tools to be used for the SDLC at Deloitte Canada and for versioning and source control are currently under review. This section of the document must be updated once a tool strategy has been decided on.

The governing policies for the tools and the processes to be used through the development lifecycle must be included or referenced in this document. Key Considerations

5.2.5 Deployment Method

Purpose

There are multiple ways to deploy solutions to SharePoint (like SharePoint Designer, Site Collection Solution Gallery, or to the farm).

The supported deployment methodology needs to be specified for each site Offering. In addition, the supported behavior should be specified per farm environment (like development, test, and production).

Defined By

Architect (SP&E Enterprise Architecture and Collaborative Solutions Group), Development Manager Collaborative Solutions Group), System Administrators (CAS)

Policy Definition

Any customizations should be deployed using SharePoint solutions (.wsp files). SharePoint Designer customizations can be packaged as WSP files natively with the Office 2010 version. This policy will apply to the development environment only as SharePoint Designer is not allowed in any other environments.

For branding work that is completed in SharePoint Designer, developers should use the tool to create the master pages, layouts, CSS, JavaScript, etc. artifacts but have a Visual Studio 2010 project template to copy the files into as well. Although this may be seen as redundant, the artifacts that exist in Visual Studio 2010 projects can be checked into version control systems and packaged up for deployment to multiple environments with a single package (.wsp file). Master pages and other branding artifacts must be applied or activated when deployed to a SharePoint farm. This should


http://blogs.msdn.com/b/sharepointdev/archive/2011/08/25/creating-your-first-tfs-build-process-for-sharepoint-projects.aspx


000Deloitte Canada0

always be accomplished through scripts. In this specific case, a feature receiver can be used to set the master page of a site to the appropriate custom master page.

Custom code for SharePoint applications or solutions should be deployed using WSP files only. The deployment of the WSP files handles the installation and configuration to all of the servers in a SharePoint farm. Moreover, the installation will automatically target the appropriate server roles. For example, installation of custom web parts will be completed on web front-end servers only as they are the only servers required and targeted for the running of web parts.

Custom assemblies such as the ones for web parts must always be deployed to the bin folder of the web application. The web.config files already have the right code access policies to allow an assembly in the bin folder to operate properly. Alternatively, depending on the .NET assemblies used by the custom web parts or compiled code, custom code access security (CAS) policies can be created. The base SharePoint Server 2010 CAS policies should always be used as a starting point.

GAC deployment should only be selected when deploying global customizations like feature staplers for site templates or any other customizations that are required across the farm and not just at the web application level. The following is a list of SharePoint customizations that must be deployed or have associated assemblies deployed to the GAC:

Field type Feature stapling code behind Custom action Coded workflow assemblies Workflow activity Workflow conditions and Information management policies

Key Considerations

An additional consideration is whether to support bin or GAC deployments. The deployment approach chosen has impact on security, need for resetting IIS during development to unload the binaries, and debugging.

5.2.6 Features

Purpose

A feature is a container for defined extensions for SharePoint Server 2010 and is composed of a set of XML files that are deployed to servers. You can deploy a feature as a part of a site definition or a solution package, and you can individually activate a feature in SharePoint Server 2010 sites.

By having new site functionality implemented as features, you make it easier for administrators to control sites and enforce a governance plan. Feature stapling enables you to attach a feature to all new instances of sites that use a given site definition without modifying the site definition. This lets you control the features that users of your service can access.

Defined By

Architects, Development Manager, Test Manager, System Administrators, Security Resource


000Deloitte Canada0

Policy Definition

Activation and deactivation of features should always be scripted and automated. All features can be activated and deactivated by code. It is important that features contain activation and deactivation code in order to configure the customization and retract the configuration of the customizations.

STSADM commands as well as PowerShell scripts can be used to deploy and activate or deactivate features. The code that runs at activation and deactivation time is executed from the assemblies associated with the features. The code will automatically run at activation and deactivation time.

Features should target the appropriate SharePoint hierarchy within a farm. The <Scope> attribute of a feature element in the Feature.XML file points to the scope. The scope can be a farm, web application, site collection, and site. Features should only target the required scope and nothing more.

The features should be packaged within a WSP. The WSP package must be deployed by the SharePoint Administration team, CAS. Furthermore, for features that have a site collection or site scope, the features can be activated/deactivated by the site collection and site administrators, respectively. However, this type of activity can only happen after the WSP feature containing the feature has been deployed by the CAS team.

Features should be deployed during maintenance windows only, especially those who target a farm or one or more web applications. Once activated, these features may cause application pool resets which should not be executed during regular business hours.

Applications and solutions should use a common framework for logging. One such framework is the Microsoft Enterprise Libraries which contain multi-threaded logging classes. With error checking expected in all of the code developed, any errors should be captured. However, instead of outputting errors in the logs as they are encountered in code, a configurable level of logging is implemented.

The Solution Architects as well as the CAS teams should be involved to validate the design of a new feature based on business requirements. This is a process that should be implemented from the beginning, in the Solution Development teams, and should be continued by the CAS team as features are deployed into the environment.

The review and the final approval for feature deployment should be given by the CAS team, the business users testing the solution out in the UAT environment, and by the Solution Development team. The solution development team should have a process where features are architected and reviewed, once implemented, to ensure they adhere to the standards define in this document.

Key Considerations

Considerations include:

Should features be deployed to the entire farm or individually (for example, as sandboxed features)?

Who deploys features?


000Deloitte Canada0

When are features deployed? What application-specific information should be logged for monitoring and troubleshooting? Who validates and approves the design of a new feature against business requirements

before it is built? Who reviews and approves the final feature for deployment?

5.2.7 Use of SharePoint Designer 2010

Purpose

SharePoint Designer 2010 is an important developer tool for the SharePoint Server 2010 platform. However, the use of SharePoint Designer 2010 should be governed in respective environments (like development, staging, and production).

The use of SharePoint Designer 2010 should be restricted. SharePoint Designer 2010 is a powerful tool, and users with adequate training who are explicitly approved to use it should be included in a group policy. This will ensure users are aware of how to use SharePoint Designer 2010 as well as what not to do. Training should be scoped to the types of activities users are allowed to perform and items they can configure. An example list might include:

Data View Web Parts Form View Web Parts Content Query Web Parts Content types Workflows Usage reports SharePoint master pages, page layouts, and styles

Note

This last bullet point should be considered exclusively for the designer or consultant.

Defined By

Architect, Development Manager, System Administrators, Security Resource

Policy Definition

SharePoint Designer 2010 should not be used in any Deloitte Canada SharePoint 2010 environment other than development. Moreover, any customizations that are implemented in SharePoint Designer 2010, in the development environments, must be implemented in a Visual Studio 2010 project and the project must be added to TFS 2010. This is required to include all customizations, regardless of what tools they were generated with, in the version and source control system.

Any customizations that are developed in SharePoint Designer 2010 should be deployed to the Development CA (new environment), QA, UAT, CA (Content Authoring), and Production using WSP packages built in Visual Studio 2010. Although SharePoint Designer 2010 can create WSP packages to automate customizations deployment, the WSP files would not be added to the version and source control system used, TFS 2010, as there is no automatic integration between these two development tools.


000Deloitte Canada0

Key Considerations

Using SharePoint Designer 2010 to customize pages without prior approval should be prohibited.

The use of SharePoint Designer 2010 to augment development is a great way to speed up the development process. However, it might prove more practical to limit all final feature packaging to .wsp files. This means all SharePoint Designer 2010 changes are migrated to Visual Studio 2010 and implemented that way.

The use of SharePoint Designer 2010 in a production environment should be discouraged in most cases. All changes should go through a complete development and testing process before going to production.

A finite list of appropriate SharePoint Designer 2010 actions should be defined for the production environment.

5.2.8 Use of SharePoint Client Technologies Like Silverlight

Purpose

SharePoint 2010 provides enhanced support for client technologies such as Windows® Silverlight™. Many customers, especially marketing department personnel, like to leverage Silverlight capabilities to create high-end visual sites.

Silverlight is an appropriate technology for SharePoint; however, inappropriate design and usage of Silverlight can drastically impact site performance. Loading a page with multiple poorly designed Silverlight controls will introduce multiple unnecessary round trips to the server.

Coding standards should define how to minimize server round trips, how to properly use technologies such as Silverlight, and to define what Silverlight capabilities are appropriate to leverage in the SharePoint environment.

Defined By

Architect, Development Manager, System Administrators

Policy Definition

HTML5 and AJAX are the technologies to be used. As Silverlight is not a W3C defined standard, Deloitte Canada has selected not to leverage this technology for any web-based applications, including SharePoint. Therefore, HTML5 and AJAX are the only technologies allowed for implementing rich client web applications.This policy supports W3C supported standards only.

Rich media web parts provided by out of the box SharePoint capabilities will be configured for HTML rendering instead of the default Silverlight client.

Key Considerations

As Deloitte Canada employees only W3C supported standards, a process to review these standards on a regular basis is recommended. This way, the latest standards are well understood and used in the environment.


000Deloitte Canada0

5.2.9 Functional (Unit) Testing

Purpose

User experiences can vary based on user audience and permission level. It’s possible that some components might be doing things with the object model that will only work when an administrator invokes it. If this turns out to be the case, a technique called “elevation of privilege” can be used to overcome it, but of course it requires additional effort to implement.

All components should be tested with several end-user accounts to validate functionality. Tests should also be run with an account of minimal privilege.

Defined By

Development Manager

Policy Definition

Include a policy on the permissions to be tested by each service offering and solution or application.

Testing of SharePoint solutions and applications has been analyzed by Microsoft and best practices are provided through the Patterns & Practices content on MSDN. Through the implementation of an enterprise scale application for Training Management and Partner Portal, guidance has been built for a range of testing strategies.

The diagram below shows the recommended test types that should be conducted by the acceptance test engineering.

Figure 10 Acceptance test engineering guidance - Testing layers

Each type of test has a distinct purpose. They are the following:

Unit tests. Unit tests are written by developers and run under a unit testing framework, such as Microsoft Visual Studio Team System or NUnit. Unit tests isolate and verify discrete units of program logic. They isolate the logic by replacing dependencies on the run-time


000Deloitte Canada0

environment, such as SharePoint, with test-provided substitutes. Isolation allows unit tests to run quickly, and developers can run unit tests frequently.

Integration tests. Integration tests differ from unit tests in that the code under test is not isolated. Integration tests are written by developers or testers. They run in a unit testing framework.

Acceptance tests. Acceptance tests consist of multiple steps that represent realistic usage scenarios of the application as a whole. These tests verify that an application meets the needs of the intended users. Their scope includes usability, functional correctness, and performance. Generally, test engineers create these tests.

For the functional or unit testing, mock object use is recommended. Mock objects are instances of test-provided classes that simulate the behavior of external components. Mock objects isolate the application code under test. They create conditions that are otherwise difficult to produce, such as a disk full exception.

Mock objects should be implemented in the following three ways:

1. Mock views: using the Model-View-Presenter (MVP) pattern, leverage the presenter classes to encapsulate business logic and update the properties of view interfaces that are provided by the top layer of the applications. Unit tests exercise the functionality of the presenter class, in isolation, to run the unit test. Additional information on the MVP pattern can be found at the following location: http://msdn.microsoft.com/en-us/library/ee413740.aspx.

2. Mock services: use a service locator to expose the components of the data layer. With this approach, access to the inputs and outputs of the presentation layer can be specifically targeted. Service locator examples can be found:

a. The Service Locator service example: http://msdn.microsoft.com/en-us/library/ee413842.aspx

b. The SharePoint Service locator: http://msdn.microsoft.com/en-us/library/ee413915.aspx

3. Tool-generated mock objects for system services: Mock views and services may not be sufficient when testing the lower layers of an application as some of the SharePoint classes may be sealed. Therefore, instead of substitution used in unit testing, impersonation of some of the SharePoint classes may be required.

When implementing code testing procedures and using mock objects, it is important to not duplicate the functionality that SharePoint has implemented natively. For example, creating a mock object that calls the SharePoint databases directly using store procedures or direct query is not necessary as this is native product functionality. The SharePoint database operations have been streamlined and a lot of performance enhancements have been built around these operations.

For additional guidance on building a unit test environment, please visit http://msdn.microsoft.com/en-us/library/ff650384.aspx. Moreover, for additional unit testing tools for web part development, the white paper and code available at the following location is recommended: http://www.21apps.com/agile/beginners-guide-to-test-driven-web-part-development/attachment/unit-testing-sharepoint-solutions-the-basics/.


http://www.21apps.com/agile/beginners-guide-to-test-driven-web-part-development/attachment/unit-testing-sharepoint-solutions-the-basics/

http://www.21apps.com/agile/beginners-guide-to-test-driven-web-part-development/attachment/unit-testing-sharepoint-solutions-the-basics/

http://msdn.microsoft.com/en-us/library/ff650384.aspx




000Deloitte Canada0

Key Considerations

Mock-up frameworks need to be used to isolate SharePoint development from the external dependencies or in some cases dependencies on other tiers in as SharePoint solution. There are several third-party mock-up frameworks available for SharePoint solution unit testing.

5.2.10 Deployment to Test and Production

Purpose

Test, staging, and production environments should all be treated the same. The way you deploy bits to the Test environment should mirror the production process to ensure proper test coverage.

Deployments are typically restricted to WSPs using Windows PowerShell for farm-deployments, or the Site Collection Solution Gallery for Sandboxed deployments.

Defined By

Development Manager, Test Manager, System Administrators

Policy Definition

Deployment to test and production environments should be performed using WSP files and PowerShell and/or STSADM scripts. Additional scripts may be required for deploying additional customizations. It is recommended any additional custom components, such as custom web services, custom, helper .NET assemblies, and custom databases should always be deployed using an automated process in order to eliminate any manual errors. If it is not possible to automate the whole deployment process then it is recommended a well-documented procedure is available.

When promoting code to UAT and production environments, the exact same package (WSP) version must be used. This should be one of the checks that is implemented by the deployment team, CAS, when accepting packages for deployment.

Additionally, when applications or solutions require configuration sections based on the environment they are deployed to, a standard should be setup. The following policies should be used for making decisions on which approach to take for this type of functionality:

1. Do not use web.config <appSettings> sections or any other sections for any of these settings. The only reason to use web.config is to leverage the .NET encryption APIs to hold a user ID and password in the file if and only if the application requires it.

2. Leverage site collection property bags to store configuration settings. This may not always be the best option as an out of the box interface is not available to easily modify the settings as the code is deployed from environment to environment. PowerShell scripts are the native way to implement this. Otherwise, an ASP.NET web page should be implemented to provide this functionality for all applications/solutions that require it.

3. Use a hidden, SharePoint list to store the configuration settings. The configuration settings can be stored in as a name-value collection and the interface to access this information and modify it is already available via the native SharePoint interfaces.


000Deloitte Canada0

Key Considerations

Some customers dedicate a resource for build and deployment. In these cases, you need to clearly define who is responsible to deploy solutions to test, stage, and production.

5.2.11 How to Package WSP

Purpose

Even though big improvements have been added to the Visual Studio 2010 environment for packaging SharePoint features it is still quite complicated for advanced solutions.

It is important to train developers and define the standard tools that should be used to package WSPs. There are numerous third party tools to support this, including many common tools on CodePlex.

Defined By

Development Manager, System Administrators

Policy Definition

WSP packages can be constructed and built using Visual Studio 2010. It is recommended a Visual Studio 2010 template or a set of templates is pre-configured and distributed to all SharePoint developers through TFS 2010. The project template should include all of the settings and configuration for building a WSP as well as a folder structure to address any type of SharePoint customization to be deployed.

Key Considerations

Visual Studio 2010 has support for packaging WSPs. Additional tools for creating WSP files can be found on web sites such as CodePlex. However, the Visual Studio 2010 projects together with proper planning and project templates can generate packages (WSP files) without the need to employee additional tools.

5.2.12 How to Deploy Web.config Entries

Purpose

Custom entries in web.config are tedious to maintain, and manual updates can create inconsistencies that will break site functionality.

The governance policy should clearly define what types of updates are supported in web.config files, and how updates should be propagated throughout the farm. For example, using the web.config to create application settings or state is not an appropriate use of web.config files. SharePoint provides other property bag techniques that are more appropriate for this type of functionality.

Defined By

Development Manager, Architect, System Administrators


000Deloitte Canada0

Policy Definition

Any SharePoint application or customization implementation that requires application wide configuration should be stored in the property bags of the site collection the application targets. Web.config <appSettings> must not be used for these purposes as they will require a separate deployment step from environment to environment. Additional information is available in section 5.2.10 above.

Key Considerations

Not applicable.

5.2.13 Feature Cleanup

Purpose

Feature deactivation does not always support removing all artifacts because of other dependencies. Policy needs to be defined as to how the dependency removal should be handled.

Defined By

Architect, Development Manager, System Administrators

Policy Definition

Implement feature clean-up unless you are unable to. Data cleanup such as documents and pages in document and pages libraries may cause errors.

Key Considerations

You can you Feature Receivers to fully remove objects. However, for complicated features that may be used throughout the farm, full removal can cause failures in pages that use the component. Another consideration is what to do with processed data. For example, in a scenario where you remove a custom workflow solution, decisions need to be made if you want to delete the document library that contains all of the processed workflow items or in-process workflow items.

Any data that is dependent on a feature that will be removed must be dealt with in advance of the feature being deactivated. There are no special instructions required for this type of clean-up other than proper planning is required prior to initiating the feature deactivation and removal.

Features that replace master pages with custom master pages are some of the easiest ones to cleanup as long as the initial deployment keeps the original, out-of-the-box master page.

Features that deploy custom content types are some of the most complicated to cleanup. Any list item, list, or document library that uses the content type must remove the dependency. Therefore, it is a very manual process, especially if the content type has been in the environment for some time and end users have had the chance to use it for a while.

Note

It is worth noting that any changes required to a component deployed by a feature can be applied through a package (WSP) file upgrade. The feature that is upgraded does not


000Deloitte Canada0

require deactivation/re-activation for an upgrade process. The WSP upgrade will automatically look after the upgrade.

5.2.14 Hotfix Support

Purpose

Developers should maintain a consistent version of SharePoint to test. This means hotfixes and service packs should be built and tested on the same version.

Defined By

Development Manager, Test Manager, System Administrators, Support Lead

Policy Definition

The current patching process must remain in place for SharePoint Server 2010. The patching environment should be used to test service packs, cumulative updates, and hotfixes. Once these are approved, they can be deployed to the other environments.

Key Considerations

Production updates typically lag behind development and test environments. It is required to test site functionality with hotfixes in the test environment prior to applying hotfixes in production.

5.2.15 Development Roles

Purpose

The SharePoint Server 2010 platform supports development at a number of levels.

For example, power users in business units can create and customize pages, change teams, and configure workflows. Power users can use SharePoint Designer 2010 to modify master pages, page layouts, and define custom workflows. Developers can create and deploy .wsp files to modify SharePoint artifacts or deploy custom applications.

Depending on the customer, any one (or all) of these might be considered development. Defining who can do what, what training they require, and in what environments changes can be made are essential to govern the platform over the long term.

Development efforts should be defined and coordinated across the SharePoint UI, SharePoint Designer 2010, and Visual Studio 2010.

An official process should be defined to approve, develop, deploy, and test customizations.

Defined By

Strategy Team, Development Manager, User Experience Manager, System Administrators

Policy Definition

The Solution Development team is the only team allowed to develop against SharePoint 2010. As the sandbox solution will not be used in any of the environments there is no need to identify additional developer roles within the Service groups or Service Lines.


000Deloitte Canada0

For more information, please refer to the accompanying document named SharePoint Development Guidance.

Key Considerations

An application-lifecycle management (ALM) should be defined for all custom development. This includes build, source control, and testing of custom development.

Developers will need refreshes from the production environment periodically to maintain a current and representative development environment against which to run unit tests.

5.2.16 SharePoint Farm Environments

Purpose

Creating the right design for a farm and configuring each environment correctly can be a challenge for organizations, especially in the area of support.

However, it is an even bigger challenge to govern the development process when the proper farm designs and configurations are not in place.

The following farms are recommended for a SharePoint environment:

Developer Sandbox

This is a standalone instance that can be installed on physical hardware or as a virtual machine. Virtual machines are typically more convenient to manage and are the standard used by Deloitte Canada.

Development Integration

This environment represents a more traditional farm where developers can verify deployment and end-to-end functionality of their solutions. Deployment to this environment is managed by CAS.

Quality Assurance (QA)

This is the official verification environment where deployment and user acceptance testing is verified. This environment should be treated similar to production, and developers should not be allowed to make changes to the code in this environment. Additionally, developers should not need to debug code directly in this environment.

Content Authoring (CA)

This is the environment where final code and content is deployed to prior to making its way into production. This environment is also used as a backup for hosting all of the content and customizations that will eventually be deployed to production and UAT

UAT

This environment is used for final user acceptance testing before deploying code and content to the production environment.


000Deloitte Canada0

Production

Any updates to this farm should have been verified in the environments stated above.

Defined By

Strategy team, Architect, Development Manager, Test Manager, System Administrators

Policy Definition

Development environments will be used to build the code. The QA and UAT environments will be used for user testing and acceptance testing. The publishing and the production environments will be used for final code only.

Key Considerations

It is often more difficult for smaller customers to build and maintain these farms and support the full testing and deployment process.

In those situations, it is common to experience deployment and production bugs that you normally would not encounter. Additionally, it is possible that the developers will need to debug issues directly in production if they do not have proper development farms to replicate issues found in a production environment.

5.2.17 Support

Purpose

Support is a necessary function to support SharePoint Server 2010 deployments.

An escalation policy should be defined for all support needs.

An example policy might read:

Support issues should be escalated in the following order:o Review the help in the support and FAQ forums.o Contact the department administrator.o Contact the corporate help desk.o Contact operations.o Contact a developer.

Note that any support request contact to operations or developers must be first escalated by the help desk.

Defined By

Strategy team, Support Lead, System Administrators, Development Manager, Test Manager

Policy Definition

Support group creates the site and a site owner identified. Each team site has two site owners and the site owners have permissions to create lists, permissions, add users, etc.

1. Helpdesk – 6600


000Deloitte Canada0

a. Helpdesk makes the decisionb. Helpdesk documents all the processes and applicationsc. Forwarded to first level support – application owners will always be involved.

2. Application owner (business and technical owners are identified) support. For example, KMO – first level support

a. Investigate the issueb. Determine whether to go to CAS or development teamc. KMO owns team sites, Gatewayd. Application owners request new features through the Portfolio Management

Service Request process3. Operations - CAS involved at server down or as decided by KMO4. Solution Development team

Key Considerations

The support policy varies based on the type of solution and also the service-level agreement (SLA). The support policy needs to account for the multiple tiers of support that needs to be provided.

5.2.18 Logging

Purpose

An effective logging strategy is an effective way to keep track of problems with applications, provide quantifiable statistics for an application's history, help troubleshoot issues, and monitor the overall health of systems.

Although Windows SharePoint Services provided verbose tracking mechanisms, reconciling the information from those logs and using it to pinpoint problems with specific applications was at times difficult, and left largely to the system itself to determine which events were important enough to record.

In previous versions of SharePoint, developers could write logs into the system event logs as well as the usage database. However, there was no simple way to correlate system events with a specific problem.

In SharePoint Server 2010, many of these shortcomings have been addressed with the correlation ID, event throttling, log file retention, and logging database.

Defined By

Information Architect or Architect

Policy Definition

Use the out of the box logging (ULS) for logging SharePoint-specific events.

The use of Windows logs: Applications, Security, System, etc. is recommended to continue, for all of the servers and services available on any farm server.

It is important to continue to use the OS Build documents to review and implement specific logging settings.


000Deloitte Canada0

For custom application development, the use of Microsoft Enterprise Libraries is recommended. The logging should be implemented using the current version of the libraries, Microsoft Enterprise Library 5.0 released May 2011. The libraries allow the logging to any medium, including Windows logs. It is recommended that the Windows Event Log be used for custom application/solution logging in order to capture the events in System Centre Operations Manager (SCOM) 2007, the tool used by Deloitte Canada to monitor production environments. Otherwise, custom code would have to be written on SCOM 2007 to parse the logging medium or repository.

Key Considerations

Event ThrottlingThe Unified Logging Service (ULS) and event logging now have a richer category-based management. You can set specific subcategories to a unique level of logging while throttling other subcategories that belong to same root category.

The event throttling settings should be specified for each environment. For example, the event throttling settings in development integration will likely be different than production.

Log-File RetentionRetaining logs is important to troubleshooting and monitoring activity. In SharePoint Server 2007, the default log-file retention policy was to set log files to generate once every 30 minutes, with a total of 96 log files at any given time. The ULS has been improved by reducing log file size by at least 50 percent. This allows a completely new approach to setting the log-file retention policy. The default setting is 14 days. A new option exists to restrict trace logs to a fixed disk size.

Event-log flood protection can also be enforced to prevent one event from flooding the event logs database.

Logging DatabaseSharePoint Server 2010 supports logging to SQL Server as well in the WSS_Logging database. It is important to factor storage capacity for this database, where to store it, and how to back it up.

5.3 Security PoliciesSharePoint provides a comprehensive security model that supports defining security roles to delegate responsibilities throughout the organization. This approach is generally referred to as role-based authorization control. This approach has significant management benefits over managing access control per user. Security policies should be defined per environment (like production, staging, and test).

These security policies are typically defined by the system administrators, and the management of policies other than those applying to System Administrator can be delegated. It is a recommended practice to define security policies to avoid jeopardizing the entire system by any one user.


000Deloitte Canada0

5.3.1 System Administrator

Purpose

System administrators are necessary to ensure basic functioning of servers and client machines. The responsibilities of a system administrator vary from environment to environment.

This should follow the standards that the customer has defined for system administrator access to local users, domain users, or domain administrators.

Defined By

System Administrators

Policy Definition

The CAS team holds this responsibility and role.

The CAS team has local administrative access across all of the environments.

System Admin (local administrative) access is given to developers in the virtual, development environments only.

Some of the developers are given site Collection administration permissions, on the QA environment, for troubleshooting purposes only, when needed.

The monitoring team is given system administration rights to all the servers in the SharePoint farms.

A single Active Directory domain should be used, the CA domain. System administrators are separated by OU in order to quickly identified accounts with elevated access.

Key Considerations

System administrators are added in the default local admin group which is called Administrator. If this is not configured well, System Administrator will not have access to any SharePoint applications other than the system resources and raw files.

5.3.2 Backup Administrator

Purpose

Backup administrators can override security restrictions for the sole purpose of backing up or restoring files.

Defined By


Policy Definition

A separate account should be used for backup operations. The backup account should have access to all the appropriate SharePoint components.

The backup administrator must have permissions to the following components on all of the SharePoint servers in the farm:


000Deloitte Canada0

The 14 hive Event logs IIS metabase Web-configuration files

The backup administrator must also have permissions to back up the SharePoint databases on the SQL Servers. A separate account can be used for backing up SQL Server databases. However, it is important the backups are scheduled to occur simultaneously.

Key Considerations

Backup Administrator should be added to the default local group called Backup Operators.

Permissions should apply to:

The 14 hive Event logs IIS metabase Web-configuration files

5.3.3 SharePoint Farm Administrator

Purpose

The farm administrator is the highest level security account in SharePoint.

Defined By


Policy Definition

A separate account used for SharePoint Farm admin in various environments.

Access to the SharePoint farm administrator is secure and only used in extreme troubleshooting scenarios.

Key Considerations

The farm administrator will be added in the default SharePoint Group called Farm Administrators.

5.3.4 Enterprise Site-Collection Administrator

Purpose

This role should be configured on each web application, and each time a new web application is created.

Defined By

System Administrators (CAS)


000Deloitte Canada0

Policy Definition

Currently, there is no need to identify enterprise site-collection administrators. The KMO is a potential candidate for this role as they are currently assigned site collection administrator rights.

Future applications or solution may require the use of this role. However, it should be very careful considered. Enterprise Site Collection Administrators can perform a lot of actions that a regular site administrator may not be able to.

Key Considerations

This is typically implemented by:

Creating an AD group (for example, Enterprise Site-Collection Administrators). Add the users you want to that group. Apply to Policy for Web Applications in Central Administration.

5.3.5 Other Security Policies

Other security policies that you will typically need to define:

Site owner. Contributor. Reader.

Note: You may use out-of-the-box permissions levels (like contributor), or you may need to create custom permission levels with custom permission settings based on customer requirements.

Other security policies typically included are:

SQL Administrator. Active Directory Resources. Enterprise Security Administrator.

6 Infrastructure Operations & Monitoring

6.1 Microsoft Operations Framework (MOF)The Microsoft Operations Framework (MOF currently at version 4.0) is a collection of integrated best practices, principles, and activities that provide comprehensive guidelines for achieving reliability in IT solutions and services.

MOF provides question-based guidance that enables you to determine what is needed for your organization now, as well as activities that will keep the IT organization running efficiently and effectively in the future.

MOF 4.0 supports the integration of any policies, tasks, or activities based on other frameworks (such as ITIL, COBIT, and ISO 20000) with the Microsoft platform.


000Deloitte Canada0

The guidance in MOF encompasses all of the activities and processes involved in managing an IT service: its conception, development, operation, maintenance, and—ultimately—its retirement. MOF organizes these activities and processes into service management functions (SMFs), which are grouped together in phases that mirror the IT service lifecycle. Each SMF is anchored within a lifecycle phase and contains a unique set of goals and outcomes that support the objectives of that phase. An IT service’s readiness to move from one phase to the next is confirmed by management reviews (MRs), which ensure that goals are achieved in an appropriate fashion and that IT’s goals are aligned with the goals of the organization.

Service management functions (SMFs) support each phase in the process model. It’s important to note that although the model describes the MOF quadrants sequentially, activities from all quadrants can occur at the same time.

Briefly, the lifecycle phases involve the following activities:

The Plan Phase provides guidance about how to plan for and optimize an IT service strategy. It helps to deliver services that are valuable and compelling for the organization, predictable and reliable, policy-compliant, cost-effective, and adaptable to changing business needs.

The Deliver Phase helps IT professionals more effectively deliver IT services, infrastructure projects, or packaged product deployments, and it ensures that those services are envisioned, planned, built, stabilized, and deployed in line with business requirements and the customer’s specifications.

The Operate Phase helps IT professionals efficiently operate, monitor, and support deployed services in line with agreed-to service level agreement (SLA) targets.

The Manage Layer establishes an integrated approach to IT service management activities. This integration is enhanced through the establishment of decision-making processes and the use of risk management, change management, and controls.

It’s important to understand the connection between sound operational practices, sound procedures, and a healthy SharePoint Server 2010 infrastructure. Well-documented, thorough operational processes and procedures ensure that all the components in an organization's environment, on which SharePoint Server relies, are managed efficiently and effectively through all the design, deployment, and supporting phases.

Changes to the components of an organization's infrastructure, such as firmware updates to routers and firewall rules changes, on which SharePoint Server relies can result in an unexpected outage. Modification in these areas can happen without the involvement of the organization's SharePoint team. By using MOF-based processes to help make sure that there is documentation of these service interdependencies, an organization can help minimize the chances of preventable outages and reduce the impact of scheduled changes.

Additional information on the MOF phases can be found at this location: http://go.microsoft.com/fwlink/?LinkId=203288.



000Deloitte Canada0

6.2 Monitoring SharePointTo ensure the availability and reliability of your SharePoint Server 2010 environment, you must actively monitor the physical platform, the operating system, and all important SharePoint Server 2010 services. Preventative maintenance will help you identify potential errors before an error causes problems with the operation of your SharePoint environment. Preventative maintenance combined with disaster recovery planning and regular backups will help minimize problems if they occur. Monitoring your SharePoint environment involves checking for problems with connections, services, server resources, and system resources. You can also set alerts to notify administrators when problems occur. Windows Server and SharePoint Server 2010 provide many monitoring tools and services to ensure that your SharePoint environment is running smoothly. The key advantages to daily monitoring are as follows:

Ensures that the performance requirements of your service level agreements (SLAs) are being met.

Ensures that specific administrative tasks, such as daily backup operations and checking server health, are being successfully completed.

Enables you to detect and address issues, such as bottlenecks in the server performance or need for additional resources, in your SharePoint environment before they affect productivity.

SharePoint Server 2010 offers a set of tools to monitor the health of the environment. As part of the monitoring of an environment’s health, Microsoft provides guidance on daily, weekly, and monthly tasks to be executed in order to ensure proper operation of a SharePoint 2010 environment. The following table lists the tools available for monitoring. The Operations Checklists, which outline the tasks, can be found as a separate section called Operations Checklist in the following document: http://go.microsoft.com/fwlink/?LinkId=203288.

Section Topic

Diagnostic logging Running SharePoint Server

Usage data and health data collection

View metrics

SharePoint Health analyzer Repair problems

Web analyzer View metrics

Diagnostics logging through the Unified Logging Service (ULS) provides a single, centralized location for logging error and informational messages related to SharePoint Server and SharePoint solutions. Additional information can be found in the following document: http://go.microsoft.com/fwlink/?LinkId=203288.

In addition to Diagnostic Logging, SharePoint Server 2010 also proactively logs information that is related to the overall health of the farm. As an administrator you can individually select which events are monitored, for example the usage of features, page load times, and search queries.





000Deloitte Canada0

SharePoint has a number of features that log and gather detailed statistics about all aspects of the health of the environment. The SharePoint Health Analyzer aggregates all of this data, identifies possible problems, then proactively looks for, and recommends solutions.

The reports that the Web Analytics functionality in SharePoint Server generates provide detailed insight into how your SharePoint environment is being used, and how well it’s performing.

6.3 Patching and hot fixesWhen rolling out SharePoint Server 2010 at Deloitte Canada, Service Pack 1 for SharePoint 2010 is already available. It is recommended all of the builds be setup with the latest service pack, in this case service pack 1.

Note

Service Pack installations, depending on where and if they fail, may not have a back-out mechanism. Therefore, it is recommended a back-out procedure is always available prior to a service pack installation.

Service Pack releases will usually have accompanying language packs. Ensure the language packs are installed alongside as well.

Service packs have two components to them:

1. The binaries – the actual DLLs and other binary files that are updated as part of a new compilation of the SharePoint code.

2. Store Procedure updates – once the binaries are deployed, usually, a set of store procedures are run to update database schemas or make specific modifications to the databases.

Once the binaries are installed, the correct version of the database schema must be available for the server to be able to connect to the databases. If any of the servers are out of sync then those servers will have to have their binaries updated if the schema has been updated.

For service packs, you must also be careful as they usually come in two separate packages: one for SharePoint Foundation and SharePoint Server 2010 and they are not mutually inclusive. Therefore, you must apply the SharePoint Foundation service packs before applying the SharePoint Server 2010 service packs.

The schema updates are usually accomplished by running the configuration wizard on the first server that finished installing the service pack binaries. Once one of the updated servers has completed the schema update, the schema update need not run any longer.

Note

Only apply hotfixes if you encounter the problem described by the hotfix. Hotfixes will all be included in the following service pack and unless you experience an issue similar to what is in the description of the article, a hotfix installation is not required.


000Deloitte Canada0

6.4 System Centre Operations Manager (SCOM) 2007A significant aspect of SharePoint Server 2010 daily operations is monitoring the health of the SharePoint components to achieve the following functions:

Generate alerts when operational failures and performance problems occur. Represent the health state of servers and server roles. Generate reports of operational health over time so that you can estimate future demands

based on usage patterns and other performance data.

The Microsoft SharePoint 2010 Products Management Pack is designed to be used for monitoring SharePoint events, collecting SharePoint component-specific performance counters in one central location, and for raising alerts for operator intervention as necessary. The management pack requires SCOM 2007 R2 or SCOM 2007 SP1.

The management pack monitors the following services:

Access Services Document Conversions Launcher Service

Document Conversions Load Balancer

Excel Calculation Services InfoPath Forms Service Managed Metadata Web Service

One Note Service PerformancePoint Service PowerPoint Web ServiceProject Server Service Project Server Events Service Project Server Queuing

ServiceSecure Store Service SharePoint Server Search User Profile ServiceVisio Graphics Service Word Conversion Service Word Viewing Service

Additional information regarding the Management Pack is available at this location: http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=4419.

6.5 Farm Administrator and SQL Administrator Policy

Purpose

Administrators will need to support sites to maintain the health of the sites. The types of tasks and how requests are escalated should be defined upfront.

Defined By

System Administrator

Policy Definition

Roles and responsibilities should be defined for this scope. The SharePoint Operations Checklist found at the following link: http://download.microsoft.com/download/8/C/3/8C34FFE4-9B41-46B0-A4B7-1DC20AEFC63B/oit2010-whitepaper-sharepoint-operations-checklist.doc provides detailed information on the daily, weekly, and monthly tasks to be executed.

Key Considerations

Administrators will need to perform various tasks depending on their role.


http://download.microsoft.com/download/8/C/3/8C34FFE4-9B41-46B0-A4B7-1DC20AEFC63B/oit2010-whitepaper-sharepoint-operations-checklist.doc

http://download.microsoft.com/download/8/C/3/8C34FFE4-9B41-46B0-A4B7-1DC20AEFC63B/oit2010-whitepaper-sharepoint-operations-checklist.doc

http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=4419

000Deloitte Canada0

Example Tasks Manage SQL databases and available store space. Implement backup and restore schedules. Audit security logs. Handle usage analysis and tuning. Install service packs on servers.

Documentation Document the installation and configuration of the environment. Document and maintain a list of scheduled tasks. Document the IT Support Team Escalation points of contact.

6.6 Enterprise Site-Collection Administrators

Purpose

Administrators will need to support sites to maintain the health of the sites. The types of tasks and how requests are escalated should be defined upfront.

Defined By


Policy Definition

The site collection administrators for the Team Site services are comprised of the KMO team members. The KMO team should be kept in this role moving forward if they are part of the end user support process. The group would require site collection access to assist end users in problems when using the internal and the external team site service.

The recommended tasks are listed in the section below and should be executed on a regular basis.

Key Considerations

Administrators will need to perform various tasks depending on their role.

Example Tasks Audit index logs to tune search and indexing. Handle usage analysis and tuning. Manage policy creation and enforcement. Determine content-crawling content sources and schedules. Identify allowable types of content. Enforce data-storage policies. Create site templates. Maintain site permissions.

Documentation Document the installation and configuration of the environment. Document the application support team and escalation points of contact. Create online documentation for training and support needs. Document the IT Support Team Escalation points of contact.


000Deloitte Canada0

6.7 Changing Passwords

Purpose

Changing service account passwords will adversely impact your SharePoint deployment. Ideally service account passwords do not change, but some customer environments require passwords changes for security purposes.

Defined By

System Administrator, Security Resource

Policy Definition

All System Admin accounts should be acknowledged to be exempt from password policy resets.

Key Considerations

Changing service-account passwords will affect the following at a minimum:

SQL Server service account Server farm account Application pool accounts Service application accounts

Procedures need to be defined to specify how the password changes will be applied in AD, SQL Server, SharePoint, IIS, and so forth to minimize downtime.

Managed Service Account capability in SharePoint Server 2010 addresses the concern for not needing to manage account passwords manually. This policy is needed in organizations that do not want to use the Managed Service Account capability because of other IT management policies.

6.8 Database Maintenance

Purpose

A healthy database server has enough headroom for databases and log files, plus enough capacity to keep up with requests.

Defined By

System Administrators, SQL Database Administrators

Policy Definition

The standard set of SQL Server database tasks should be implemented, as usual. The DBAs will manage the SQL Server portion of the SharePoint Server 2010. This is the first time the DBAs will be directly involved in the SharePoint deployment at Deloitte Canada.

Key Considerations

Establish server monitor and DBA tasks to for you SQL Environment.

Examples:


000Deloitte Canada0

Limit content databases to 150 GB. Limit memory usage to less than 70 percent. Limit free disk space to more than 25 percent. Limit CPU usage to less than 70 percent.

6.9 Applying Patches

Purpose

It is important to keep current by applying the latest cumulative updates, and service packs. These updates contain important product enhancements and improvements. However, be sure that you thoroughly test these updates on the pre-production environments before you apply them to the production environments.

Defined By


Policy Definition

Use the patching environment to implement Cumulative Updates and Service Packs and then test and wait for a couple of months to ensure there are no issues with the updates.

Once the patching environment is cleared, advise the development team about the upcoming patching work during maintenance window. The downtime for MS patches is limited to the maintenance window. Individual Dev environments, Dev (Integration) & QA environments are updated first and then the rest follow. When updating multi server environments, it is recommended a server rotation is implemented. The first web front-end server to be updated should update the database(s) as well, if required by the update. The follow-on servers can be taken offline and updated while the servers updated first, along with the database servers, remain active for the end users to access the services and applications.

Key Considerations

Policies should specify:

What is the test signoff procedure for patches and service packs? When to apply updates (for example, off-hour time windows). How to apply updates in the production environment to minimize downtime (for example,

rotate servers out of rotation).

6.10 Managing Log Files

Purpose

Log files can grow and take up unnecessary disk space. In some cases a log file can consume all available disk space making the server inoperable.

Defined By



000Deloitte Canada0

Policy Definition

It is recommended the log files are kept based on the 14 day, default cycle. Additionally, if disk space becomes a concern, there is a secondary setting that can limit the log growth to a specific disk space amount.

Key Considerations

Back up log files, in addition to data files, so that the log files can be truncated.

Back up usage logs, IIS logs, transaction logs, and SMTP e-mail logs as well.

Specify how often log files should be backed up and where they are stored.

6.11 Monitoring and Cleaning Up Sites

Purpose

Team sites are often self-service and loosely structured to make collaboration easier.

Defined By

System Administrators, Business Owners

Policy Definition

Business owners and site owners should be responsible for this task. Application owners must be made aware of growth. Archiving policies must be implemented and users must be trained on how to use the archiving system, once implemented.

Application owners should define and identify the content archiving. How long should content be kept within site? What happens when a site becomes dormant for a set period of time?

What happens to outdated data in the SharePoint sites?

While the new archiving tool and policies are implemented, reporting requirements should also be identified. The reports, both site owner targeted as well as Operations (CAS) targeted, should be available a few months to a year after the implementation of the archiving tool and policies. The report will make it easier to show business users if content does meet archiving policies.

Key Considerations

Establish and communicate appropriate service-level agreements (SLAs) for content archival and content deletion. Consider that team sites often have limited life-spans that are determined by the projects they support. Use lifecycle management to remove and archive inactive sites regularly.

6.12 Enforcing Site and Content Size Limits

Purpose

Enforcing size limits for sites collections, sites, and lists will help prevent unnecessary site downtime.

Defined By

System Administrators, Business OwnersPage 86


000Deloitte Canada0

Policy Definition

This is currently enforced through site quota templates and upload file size limit. The recycle bin is also capped by the KMO team to allow for a good clean up cycle.

Key Considerations

Establish guidelines for managing site collections, sites, lists, and documents according to business needs, including the following:

Example only and not a recommendation:

50,000 site collections per content database. 500 MB per site collection (default quota maximum). 50 MB file size limit (recommended) up to 2 GB (maximum). 2000 items per list view.

6.13 Backup Policies

Purpose

When you work with SharePoint Server 2010 deployments, you must ensure that you plan backup and restore policies to cope with disasters. SharePoint Server 2010 offers out-of-the-box backup and restore capabilities. However, when you plan for disaster recovery and high availability, you should consider alternative approaches based on your specific environment and Service Level Agreements (SLAs). These approaches include Microsoft SQL Server failover clustering, and other third part products.

Defined By

Strategy Team, System Administrators

Policy Definition

The current policy should be leveraged:

Windows Server backup – 14 hives, full Windows OS backup, database backup, solution files. Daily full backups Backup retention is 14 days. Done to inexpensive disk. Backup goes to disk (local) and then

tape (remote site)

A more frequent content database backup should be used in the SharePoint 2010 environment. For example, the SQL Server transaction logs should be backed up twice a day in order to have a more frequent backup than the current, daily full database backup.

If all of the above backup processes are implemented then there is no need to implement a regular native SharePoint backup process. However, a weekly, or monthly SharePoint farm backup should be conducted in order to have a quick restore point in case of a catastrophic failure.


000Deloitte Canada0

Key Considerations

Backup Types Full backup Differential backup Partial backup Transaction-log backup

Backup StrategyFull database backups can be time-consuming and will almost certainly have an adverse effect on the performance of the database during the backup process. In most scenarios, you should schedule full backups for low usage, non-operating hours when user demand for your databases is at a minimum, such as overnight on a weekend. You may consider interspersing your full backups with a series of differential backups. For example, a common scenario involves performing a single full backup per week, complemented by a differential backup for the six days between each full backup. You can also further intersperse your full and differential backups with transaction-log backups. You can use transaction-log backups more regularly since they do not affect database access times for your users.

What to Back UpThe number and types of databases that you will need to back up depend on your farm topology. In addition to the configuration and content databases, be sure to back up your search databases, managed metadata services databases, and any other databases that you have in your deployment. The backup should also include backup of any configuration settings on the Web front-end servers and the application servers.

Backup FrequencyWithin your backup strategy ,it’s important to specify how often to back up databases, along with the backup type that you will use.

Backup RetentionYou need to store transaction-log backups for up to 24 hours (until the next full or differential backup), and you need to store the latest differential backup for up until the next full backup. Different scenarios will require different schedules. For example, if the size of your differential backup approaches the size of your full backup, you should probably conduct a full backup on a more regular basis.

Using SQL SnapshotsA snapshot is essentially a read-only point-in-time backup of the database. You can point a Web application at this backup snapshot and allow users access to data without performing a full restore.

Note: A snapshot relies on having access to the primary database. Therefore, you should not consider database snapshots to be a full backup solution. They are an opportunity to offer your users a high level of availability and content database versioning.


000Deloitte Canada0

6.14 Disaster Recovery

Purpose

When you deploy your SharePoint Server 2010 environment, you must consider the different failover solutions available to you. SQL Server provides server log shipping, database mirroring, and failover clustering solutions that you can implement to provide high availability in the event of failure or disaster. Each failover solution offers its own advantages and disadvantages that you should take into consideration when you plan your deployment.

Defined By

Strategy Team, System Administrators

Policy Definition

For the SharePoint 2010 deployment, the disaster recovery plan will employ what is known as a stretched farm. A stretch farm provides disaster recovery between two, high speed connected, data centers. Deloitte Canada is planning to use the Bell as the primary data center and the Telus data center as secondary. The cross load balancing is used across the two data centers and SQL Server mirroring can be used. Bell data center will host the primary databases. The Telus data center will be the failover SQL Server mirror.

The following diagram provides a high-level view of a stretched farm.


000Deloitte Canada0

Figure 11 High-level stretched SharePoint 2010 farm

Failover and failback tests should be performed during maintenance windows.

Key Considerations

Disaster recovery is a complicated process that requires extensive planning and evaluation of potential solutions.

Traditional approaches are based on:

Log shipping Mirroring Failover clusters

Each approach has its advantages and disadvantages.


000Deloitte Canada0

6.15 Custom Governance Policies<<This section could be used to document any custom Deloitte Canada policies or any policies that do not fit into the categories defined in this document. Use the same policies template to establish consistency across the document.>>

<<Custom Policy>>

Purpose

<<This section should be used to document the purpose of the policy. The section could also be used to highlight the importance and relevance to the business or technical design. Each policy template defined in this document is prepopulated with the purpose of the policy. You can change the contents to accommodate for your specific engagement requirements.>>

Defined By

<<The section should be used to document the roles responsible for defining this policy. Each policy template defined in this document is prepopulated with the typical roles responsible for defining this policy. You can change the contents to accommodate for your specific engagement requirements. >>

System Administrators, Business Owners, Architects

Policy Definition

<<This section should be used to document the policy definition. This section needs to be as precise and concise as possible. This section can act as the input to the specification for the implementation of the policy.>>

<<Insert your policy definition here.>>

Key Considerations

<<The section should be used to document the key considerations for the policy. Each policy template defined in this document is prepopulated with the key considerations we have gathered based on a combination of customer experience, lab work, or input from product groups. You can change or augment to the contents to accommodate for your specific engagement requirements.>>


000Deloitte Canada0

7 Training PlanThe human element is, after the governance plan itself, the most important ingredient in the success or failure of a SharePoint Server 2010 deployment. A comprehensive training plan should show how to use SharePoint Server 2010 according to the standards and practices that you are implementing and explain why those standards and practices are important. The plan should cover the kinds of training required for specific user groups and describe appropriate training tools. The following table lists some considerations for developing a training plan.

Training

All users of the system will require some form of training.

Business owners need education about the product, including capabilities.

Site owners need advanced training, including office integration and security policies.

End users need usage-overview training.

Help-desk personnel require intense training and troubleshooting analysis. Tier two or tier three support should be considered for official, externally provided training.

Training approach should begin by covering elementary tasks and progress to more difficult tasks, culminating in administrator level tasks and administrator “certification.”

Training tools may include:

“How to” documentation (such as what exists today) Instructor-led training hosted by the portal administrator or other competent individuals Online labs hosted on a sandbox environment

Training will initially consist of online reference materials for both typical end users (addressing “how to” information) and system administrators (addressing more technical issues such as SharePoint Services deployment best practices).

Pillar Feature area requiring training

Content Managed Metadata Service, Records Management (Records Centre, OpenText), Web Content Management, as it related to the content pillar

Search Site Collection Administration (search and FAST search links)

Insights Business Intelligence features such as Excel Services, Reporting, and PerformancePoint (dashboards and scorecards), KPI lists and web parts

Composites No code solutions using: Visio and Access services, Page 92


000Deloitte Canada0

SharePoint Designer and InfoPath, workflows and forms, External Content Types, Business Connectivity Services

Sites Foundational sites and site collections, site customization, create sites and web pages, site administration, site customization, workflows, collaboration experience, lists, list management,

Communities Wikis, blogs, collaboration experience, content tagging, My Sites, integration with Office Communication Server (or Lync), Exchange, Managed Metadata Service

7.1 Openly Available Microsoft Training & Resource Material

Resource Level Audience Description

Microsoft.com training material

Basic • End users new to SharePoint

• Site Owners new to SharePoint

Web-based self-paced lessons with a slide-deck-like interface and Audio accompaniment. Each lesson takes about 20 to 30 minutes to complete. Each topic includes an introduction and various how-to’s and capability reviews. Topics include:

• Document Libraries• Calendar• Slide libraries• Workflows

Microsoft.com demo and end-user material



• Administrators new to SharePoint

A collection of demos and instructions that cover a wide range of topics catering to one or more of the basic user types (end users, site owners, and administrators). Topics include:

• General SharePoint uses• Configuring SharePoint to receive

email• Deploying templates• Collaboration hints and tips• Workflows• Calendars• Document libraries• Slide libraries/presentations• Meeting workspaces• Check-in/check-out• Backing up files & content


http://office.microsoft.com/en-us/sharepoint-server-help/CL010257455.aspx?CTT=97



http://office.microsoft.com/en-us/sharepoint-server-help/take-sharepoint-server-2010-training-at-your-desk-HA101859255.aspx?CTT=1

http://office.microsoft.com/en-us/sharepoint-server-help/take-sharepoint-server-2010-training-at-your-desk-HA101859255.aspx?CTT=1

000Deloitte Canada0

• KPI and dashboards• Provisioning• Publishing/publishing sites

Microsoft.com video material

Basic • Users new to SharePoint

Videos that introduce very high-level content. These materials are also used as part of the communication plans. Topics include:

• Top 10 SharePoint tips• Getting started in SharePoint

Microsoft.com self-help material



A series of articles to address a wide range of questions and how-to’s (similar to the content found in the help section of any Office product). General topics include:

• General Introduction• Business intelligence• Business Process and forms• Collaboration• Content Management• Customization• People and personalization• Search

Microsoft SharePoint Team blog site

Intermediate • Site Owners• Administrators• Developers

A collection of blogs on various SharePoint topics such as records management, development behind the scenes, engineering support, end user documentation, development center…etc.

Microsoft TechNet

Intermediate / Advanced

• Developers• Administrators

Microsoft website that provides overviews, support, and in-depth how-to’s and explanations for a wide variety of SharePoint topics including:

• Getting started and general information

• Authentication• Backup, Recovery, and availability• Designing and building sites• Document management• Extranet• Geographically distributed sites• Governance


http://technet.microsoft.com/en-CA/sharepoint/ee263917.aspx

http://technet.microsoft.com/en-CA/sharepoint/ee263917.aspx

http://sharepoint.microsoft.com/blog/Pages/default.aspx



http://office.microsoft.com/en-us/sharepointserver/FX101211721033.aspx



http://office.microsoft.com/en-us/sharepoint-server-help/CL100315293.aspx?CTT=5&origin=HA101859255

http://office.microsoft.com/en-us/sharepoint-server-help/CL100315293.aspx?CTT=5&origin=HA101859255

000Deloitte Canada0

• Installation• Interoperability• Migration & upgrades• Performance capacity planning• Updates• Content management

Microsoft’s SharePoint Start site for developers

Basic • Developers A web-based resource for new .NET developers using the SharePoint platform.

MSDN SharePoint developers site

Basic / Intermediate / Advanced

• Developers A web-based resource for SharePoint developers.

Microsoft downloads – SharePoint 2010 training

Basic / Intermediate

• Administrators• Site Owners who

want further expertise

A downloadable SharePoint Learning Kit installed on SharePoint 2010 designed to demonstrate basic to advanced features for administrators including collaboration, business processes and forms, portals, personalization, search, business intelligence, and enterprise content.

Web part development

Intermediate/

Advanced

• Developers http://msdn.microsoft.com/en-us/sharepoint/ee513148.aspx

For business analyst training, please contact Zaibeen Ismail.

Additionally, training plans are available from Microsoft Learning, for the following topics:

Learning plan for Designing and Developing Microsoft SharePoint 2010 Applications:

http://learning.microsoft.com/manager/LearningPlanV2.aspx?resourceId=d8f87521-4991-4685-adfb-dfc6c66a725a&clang=en-US&cats=d4e8e42c-3d5a-4a6e-915d-d99556a49bd7

Learning plan for configuring Microsoft SharePoint Server 2010

http://learning.microsoft.com/manager/LearningPlanV2.aspx?resourceId=9173b319-2607-4954-9418-010059016602&clang=en-US&cats=d4e8e42c-3d5a-4a6e-915d-d99556a49bd7

Learning plan for Introducing Microsoft SharePoint Server 2010 and SharePoint Foundation 2010 to IT Professionals and Developers








http://www.microsoft.com/download/en/details.aspx?id=6184



http://msdn.microsoft.com/en-CA/sharepoint/gg153540.aspx






000Deloitte Canada0

http://learning.microsoft.com/manager/LearningPlanV2.aspx?resourceId=810565e4-5973-4dec-86d5-e0eac37dc4e9&clang=en-US&cats=d4e8e42c-3d5a-4a6e-915d-d99556a49bd7

Learning Plan for Developing Solutions on Microsoft SharePoint Server 2010

http://learning.microsoft.com/manager/LearningPlanV2.aspx?resourceId=64c0d890-52de-4e7c-a59b-40930c2d6657&clang=en-US&cats=d4e8e42c-3d5a-4a6e-915d-d99556a49bd7

Learning Plan for Microsoft SharePoint Server 2010 Specialist

http://learning.microsoft.com/manager/LearningPlanV2.aspx?resourceId=1f1df988-ae0c-4400-b94b-4ede9d320795&clang=en-US&cats=d4e8e42c-3d5a-4a6e-915d-d99556a49bd7

7.2 Training providers Critical Path Training

http://www.criticalpathtraining.com/Pages/default.aspx

Mindsharp

https://www.mindsharp.com/

SharePoint Boot Camp

http://sharepointbootcamp.com/








000Deloitte Canada0

8 Individual Roles and ResponsibilitiesThe roles and responsibilities in the operations team, development team, support team, and users of the solution can be further deconstructed as shown in this diagram.

Figure 1: Individual Roles and Responsibilities

Role Responsibilities and tasks Tactical teamPeople performing the role


Responsible for the acquisition, installation, and maintenance of the hardware infrastructure. Provide day-to-day operation support to portal

team Review existing infrastructure setup and develop

best practices and operation guidelines Install software that supports the environment Install operating-system security updates Install operating-system updates, upgrades, and

service packs Maintain system, application, security, and

SharePoint and IIS event logs Maintain registry settings and environmental

settings Manage Windows cluster services

Operations Team


000Deloitte Canada0

Manage network load BalancingBackup Administrator

Responsible for backing up the whole SharePoint environment. SQL Server backup (shared with SQL Admin) IIS backup SharePoint backup

Operations Team

SharePoint Farm Administrator

Responsible for global portal and WSS configuration, shared services, policies, procedures, and portal vision and SharePoint configuration:

1. Application Management SharePoint Web-application management SharePoint site management External service connections SharePoint Server shared services Application security Search administration Workflow management

2. Operations

Topology and services Security configuration Logging and reporting Upgrade and migration Global configuration Backup and restore Data configuration Content deployment

3. Services and Service Application Administration

Operations Team

SQL Administrator

SQL backups and restores (plan for backup and restore and maintain the SLA)

SQL maintenance SQL security and performance tuning Manage SQL Cluster Services

Operations Team

Active Directory Resources

Responsible for ensuring the portal is using AD appropriately.

Assist with setting up the portal to use AD for authentication Assist in synchronization of portal with AD Set SPNs and Kerberos settings

Operations Team

Enterprise Site Collections Administrator

Responsible for all site collections on a Web application.

Site Collection Level: Search settings Search scopes Search keywords Recycle bin Site directory settings Site-collection usage reports Storage-space allocation Site-collection features Site hierarchy Portal site connection Site-collection audit settings Audit log reports

Operations Team


000Deloitte Canada0

Site-collection policies Site-collection object cache Site-collection cache profiles Site-collection output cache Variations Variation labels Translatable columns Variation logs

Site Level: Regional settings Site libraries and lists Site-usage reports User alerts RSS Search visibility Sites and workspaces Site features Deleting this site Site output cache Content and structure

Site Galleries: Site content types Site columns Site templates List templates Web Parts Workflows Master pages and page layouts

Look and Feel: Master page Title, description, and icon Navigation Page layouts and site templates Welcome page Tree view Site theme Resetting to site definition Searchable columns

Site Actions: Edit Page Create Page Create Site Show Page Editing Toolbar View All Site Content View Reports Site Settings Manage Content and Structure

Enterprise Security Administrator

Responsible for managing security on the site collection level to create and change permission levels on the Web site and assign permissions to users and groups.

Note: Automations will try to minimize role demand and delegate some responsibilities to Site Owners and Contributors.

Support Team

Site Owner (Team Sites)

Primary and secondary site owner.Site Actions:

Edit a Page Create a Page Show Page Editing Toolbar View All Site Content

Operations TeamSupport Team


000Deloitte Canada0

View Reports Site Settings Manage Content and Structure

Site Administration: Regional Settings Site libraries and lists Site usage reports User alerts Content and structure

Galleries: Site content types Site columns Web Parts Master pages and page layouts

Look & Feel: Master page Title, description, and icon Navigation

User and Permissions: People and Groups (view only) Advanced permissions (view only)

Site Owner (Publishing)

Primary and secondary site owner.Site Actions:

Edit a Page Create a Page Show Page Editing Toolbar View All Site Content View Reports Site Settings Manage Content and Structure

Site Administration: Regional settings Site libraries and lists Site usage reports User alerts Content and structure

Look & Feel: Title, description, and icon

User and Permissions: People and Groups (view only) Advanced permissions (view only)

Operations TeamSupport Team

Contributor Contributing contents (for example add, delete, and edit specific items).

End User

Reader Read and subscribe to alerts and RSS feeds. End User

Developer Responsible for building the framework and features of the portal. Build the SharePoint look and feel Modify SharePoint templates as needed Build new Web Parts Write Microsoft ASP.NET code Participate in design tasks as needed Participate in development and testing as

needed

Development Team

Product

Management

Responsible for business advocacy and satisfied stakeholders. Development Team


000Deloitte Canada0

Program

Management

Responsible for resources and features advocacy. Deliver solution within project constraints Coordinate optimization of project constraints

Development Team

Architecture Responsible for designing solutions within project constraints. Development Team

Tester Responsible for approving solution for release, confirming that all issues are identified and addressed.

Development Team

User Experience

(SharePoint

Designer)

Responsible for maximizing solution usability and enhancing user effectiveness and readiness.

Connect with SharePoint Designer Change images, CSS, master pages, and layouts (drafts only) User-Interface responsibilities

Development Team

Release and

Operations

Responsible for smooth deployment and transition to operations. Development TeamOperational Team


000Deloitte Canada0

9 Governance ToolsThis section lists tools that could be useful for the enforcing and management of governance policies. The third-party tools are not recommendations from Microsoft.

Microsoft System Center Operations Manager for SharePoint – Manage SharePoint 2010 performance and latency.

Universal SharePoint Manager 2007 – Farm reporting, Central Management Console, site security analyzer, remove accounts, and clone account security.

Quest – Site Administrator: Enforce global policies and handle site discovery. Freeware for finding servers and sites and handle SQL and storage usage reporting.

AvePoint – DocAve SharePoint Administrator, compliance, security, storage monitoring, and DocAve recovery.


000Deloitte Canada0

10 References Creating your first TFS Build Process for SharePoint Projects:


Improving Application Quality Through Testing


Getting started with development for SharePoint Foundation


Productivity Hub 2010 – End-user training kit that can be installed on SharePoint 2010


Using features in SharePoint Foundation







