Você está na página 1de 109

Page i

SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 1.0 Final
Prepared by Radu.Vaduva@microsoft.com
"Document1" last modified on 16 Jul. 14, Rev 2


SharePoint Server 2010 Operating Model
Deloitte Canada SharePoint 2010 deployment

Prepared for
Deloitte Canada
Wednesday, 16 July 2014
Version 1.0 Final
Prepared by
Radu Vaduva
Principal Consultant
raduv@microsoft.com


Page ii

SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 1.0 Final
Prepared by Radu.Vaduva@microsoft.com
"Document1" last modified on 16 Jul. 14, Rev 2

Revision and Signoff Sheet
Change Record
Date Author Version Change reference
July 11
th
,
2011
Radu V. 0.1 Draft template document for the Operating Model.
Aug 26
th
,
2011
Radu V. 0.2 Draft document for review.
Sept 6
th
,
2011
Radu V. 0.3 Final document for review by the team.
Sept 21
st
,
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 21
st
,
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 iii

SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 1.0 Final
Prepared by Radu.Vaduva@microsoft.com
"Document1" last modified on 16 Jul. 14, 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 iv

SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 1.0 Final
Prepared by Radu.Vaduva@microsoft.com
"Document1" last modified on 16 Jul. 14, 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 v

SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 1.0 Final
Prepared by Radu.Vaduva@microsoft.com
"Document1" last modified on 16 Jul. 14, 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
6.8 Database Maintenance .......................................................................................................... 85
Page vi

SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 1.0 Final
Prepared by Radu.Vaduva@microsoft.com
"Document1" last modified on 16 Jul. 14, Rev 2

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

Prepared for Deloitte Canada
Page 1

SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 1.0 Final
Prepared by Radu.Vaduva@microsoft.com
"Document1" last modified on 16 Jul. 14, Rev 2

1 Introduction
The 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.
Prepared for Deloitte Canada
Page 2

SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 1.0 Final
Prepared by Radu.Vaduva@microsoft.com
"Document1" last modified on 16 Jul. 14, Rev 2

1.1 Audience
This 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.

Prepared for Deloitte Canada
Page 3

SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 1.0 Final
Prepared by Radu.Vaduva@microsoft.com
"Document1" last modified on 16 Jul. 14, Rev 2

2 Business Goals
As 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.
Prepared for Deloitte Canada
Page 4

SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 1.0 Final
Prepared by Radu.Vaduva@microsoft.com
"Document1" last modified on 16 Jul. 14, Rev 2

3 Technical Strategy
Some 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.
Prepared for Deloitte Canada
Page 5

SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 1.0 Final
Prepared by Radu.Vaduva@microsoft.com
"Document1" last modified on 16 Jul. 14, Rev 2

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 teams 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.
Prepared for Deloitte Canada
Page 6

SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 1.0 Final
Prepared by Radu.Vaduva@microsoft.com
"Document1" last modified on 16 Jul. 14, Rev 2

4 Teams
SharePoint 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 Team
This 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 firms 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. Its 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.
Prepared for Deloitte Canada
Page 7

SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 1.0 Final
Prepared by Radu.Vaduva@microsoft.com
"Document1" last modified on 16 Jul. 14, Rev 2

SharePoint 2010
Governance Teams
Strategy Team
Tactical Team
The SharePoint 2010
strategy and tactical
teams deal with
SharePoint as a
platform.
Program or Project dependent on SharePoint
2010
ICD
ICD
O&E
O&E
Gateway
Gateway
Others
Others
Project or Program
Teams with specific
requirements and
governance
Specific Project and Programs
leveraging SharePoint 2010
environments must follow
SharePoint 2010 governance
policies.
New SharePoint 2010 business
requests for additional features or
more open capabilities use should
be presented to the Strategy
Team.
Any broad decisions to support
additional features in the platform
will be communicated from the
Strategy Team to the Tactical
Team in order to implement
additional policies.

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
Prepared for Deloitte Canada
Page 8

SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 1.0 Final
Prepared by Radu.Vaduva@microsoft.com
"Document1" last modified on 16 Jul. 14, Rev 2

the follow-up on the
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)
Prepared for Deloitte Canada
Page 9

SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 1.0 Final
Prepared by Radu.Vaduva@microsoft.com
"Document1" last modified on 16 Jul. 14, Rev 2

Assurance & Advisory CSL Managing the overall design
and functionality integrity of
SharePoint from a business
perspective. The SharePoint
Business Owner doesnt 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 doesnt 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 doesnt 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 doesnt have
to be an IT expert, but the job
function typically includes
responsibility for internal
communications, intranet
portals, external
communications, and
external portals.
Tax CSL Managing the overall design
Prepared for Deloitte Canada
Page 10

SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 1.0 Final
Prepared by Radu.Vaduva@microsoft.com
"Document1" last modified on 16 Jul. 14, Rev 2

and functionality integrity of
SharePoint from a business
perspective. The SharePoint
Business Owner doesnt 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 Team
The 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
Prepared for Deloitte Canada
Page 11

SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 1.0 Final
Prepared by Radu.Vaduva@microsoft.com
"Document1" last modified on 16 Jul. 14, Rev 2


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.
Prepared for Deloitte Canada
Page 12

SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 1.0 Final
Prepared by Radu.Vaduva@microsoft.com
"Document1" last modified on 16 Jul. 14, Rev 2

Operations
Operations
Support Solution Delivery
KMO
SPE
Collaborative
Application
Systems
(CAS)
CA DBA
Support
End User
Training
End User
Support
Helpdesk
Collaborative
Solutions
Group
Developers
Solution
Architects
Application
Architects
Information
Architects
Enterprise
Architecture
QA Team
Load Testing
Service Owners
Support Development
System
Administrator
SQL
Administrator
Security
Resource
SP&E Security
Support Lead
Support
Service
Desk
Development
Manager
US-I
US-I Leads
Architect Test Manager
User
Experience
Manager

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.
Prepared for Deloitte Canada
Page 13

SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 1.0 Final
Prepared by Radu.Vaduva@microsoft.com
"Document1" last modified on 16 Jul. 14, Rev 2

Support Support Lead Support Service desk
(Amanda Palma)
Define the policies for support
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 team
At the time of this documents 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.
Prepared for Deloitte Canada
Page 14

SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 1.0 Final
Prepared by Radu.Vaduva@microsoft.com
"Document1" last modified on 16 Jul. 14, Rev 2

Executive Sponsors
Global CIOs
SharePoint Governance Working Group
Select Member Firm CTOs and Enterprise Architects
Business Constituencies
SharePoint Platform Governance Board /Steering Committee
Sponsor
Drive
Operate
UK, NL, DE, US, CA, ZA, MX
Marc Zuili (FR), Eric Ubels (NL), Stephen Mansfield (CA), Claudio Ewald (BR),
Jerome Oglesby (US/OIM), Quintin McGrath (OIM)
Execute
Across member firms
SharePoint Governance Champions
S
t
r
a
t
e
g
i
c

D
i
r
e
c
t
i
o
n
I
s
s
u
e

E
s
c
a
l
a
t
i
o
n
Already In Place
Deloitte Canada
SharePoint
Governance Teams
Strategy Team
Tactical Team
Deloitte CA Strategy Team presence
Stephen Mansfield
Deloitte CA Tactical Team Presence
Michael Minnie
Additional Participation based on Architecture,
SD, and Operations

Figure 4 Recommended Deloitte Canada interactions with Global SharePoint governance teams

Prepared for Deloitte Canada
Page 15

SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 1.0 Final
Prepared by Radu.Vaduva@microsoft.com
"Document1" last modified on 16 Jul. 14, Rev 2

5 Governance Policies
Each 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.


Enterprise
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

Prepared for Deloitte Canada
Page 16

SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 1.0 Final
Prepared by Radu.Vaduva@microsoft.com
"Document1" last modified on 16 Jul. 14, Rev 2

5.1 Information Governance Policies
Defining 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
Prepared for Deloitte Canada
Page 17

SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 1.0 Final
Prepared by Radu.Vaduva@microsoft.com
"Document1" last modified on 16 Jul. 14, Rev 2

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
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)
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
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)
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
Prepared for Deloitte Canada
Page 18

SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 1.0 Final
Prepared by Radu.Vaduva@microsoft.com
"Document1" last modified on 16 Jul. 14, Rev 2

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
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 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.
Prepared for Deloitte Canada
Page 19

SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 1.0 Final
Prepared by Radu.Vaduva@microsoft.com
"Document1" last modified on 16 Jul. 14, Rev 2

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)
Prepared for Deloitte Canada
Page 20

SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 1.0 Final
Prepared by Radu.Vaduva@microsoft.com
"Document1" last modified on 16 Jul. 14, Rev 2

Ensure a process is setup to monitor and plan for provisioning new web applications when
the limits are approached.
Web application: Deloitte (Collaboration) Team Sites
Team1 Team2 Team3
http://TBD.collab.ca
Web application: Assurance & Advisory Team Sites
Team1 Team2 Team3
http://TBD.collab.ca
Web application: Consulting Team Sites
Team1 Team2 Team3
http://TBD.collab.ca
Web application: Enterprise Risk Team Sites
Team1 Team2 Team3
http://TBD.collab.ca
Web application: Financial Advisory Team Sites
Team1 Team2 Team3
http://TBD.collab.ca
Web application: Tax Team Sites
Team1 Team2 Team3
http://TBD.collab.ca

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
Prepared for Deloitte Canada
Page 21

SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 1.0 Final
Prepared by Radu.Vaduva@microsoft.com
"Document1" last modified on 16 Jul. 14, Rev 2

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.
Prepared for Deloitte Canada
Page 22

SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 1.0 Final
Prepared by Radu.Vaduva@microsoft.com
"Document1" last modified on 16 Jul. 14, Rev 2

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
Prepared for Deloitte Canada
Page 23

SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 1.0 Final
Prepared by Radu.Vaduva@microsoft.com
"Document1" last modified on 16 Jul. 14, Rev 2

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
Prepared for Deloitte Canada
Page 24

SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 1.0 Final
Prepared by Radu.Vaduva@microsoft.com
"Document1" last modified on 16 Jul. 14, Rev 2

Delete Versions
Browse
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
Prepared for Deloitte Canada
Page 25

SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 1.0 Final
Prepared by Radu.Vaduva@microsoft.com
"Document1" last modified on 16 Jul. 14, Rev 2

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
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.
Active Directory
User
Active Directory
Group
SharePoint
Permissions
SharePoint Group
SharePoint Site Owner
SharePoint Site Owner
End User accessing
SharePoint Site
End User accessing
SharePoint Site

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.
Prepared for Deloitte Canada
Page 26

SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 1.0 Final
Prepared by Radu.Vaduva@microsoft.com
"Document1" last modified on 16 Jul. 14, Rev 2

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
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
properties
b. Editing items
c. Checking out or checking in items
d. Moving or copying items to another location in the site
e. Deleting or restoring items
2. What events to log for lists, libraries, and sites:
a. Editing content types and columns
b. Searching site content
c. Editing users and permissions
Prepared for Deloitte Canada
Page 27

SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 1.0 Final
Prepared by Radu.Vaduva@microsoft.com
"Document1" last modified on 16 Jul. 14, Rev 2

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.
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
Prepared for Deloitte Canada
Page 28

SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 1.0 Final
Prepared by Radu.Vaduva@microsoft.com
"Document1" last modified on 16 Jul. 14, Rev 2

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
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
Its 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
Prepared for Deloitte Canada
Page 29

SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 1.0 Final
Prepared by Radu.Vaduva@microsoft.com
"Document1" last modified on 16 Jul. 14, Rev 2

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.
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.

Prepared for Deloitte Canada
Page 30

SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 1.0 Final
Prepared by Radu.Vaduva@microsoft.com
"Document1" last modified on 16 Jul. 14, Rev 2

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.
Team Sites and External Team Sites Lifecycle Management
S
t
a
g
e

2
S
t
a
g
e

1
S
t
a
g
e

3
S
t
a
g
e

4
3 Years 1.5 Years 1.5 Years
Site Collection is
created
Site
Administrator
Decision to
archive site
Extend Lifecycle for
site by another 1.5
years
No
Archive to
Online Archive
Yes
Has Site
content been
modified
within the past
1.5 years?
Online Archive is available to
end users to retrieve archived
content. Online tools
required to minimize Support
and CAS involvement.
Archive to Offline
Archive and
Remove from
Online Archive
Yes
No
Offline Archive is available to
CAS and Support groups only.
End users must submit
requests to retrieve archived
content after 3 years.
Remove from
Offline Archive and
Delete Content

Figure 8 Team Site Lifecycle
Prepared for Deloitte Canada
Page 31

SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 1.0 Final
Prepared by Radu.Vaduva@microsoft.com
"Document1" last modified on 16 Jul. 14, Rev 2

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 years
2. Request for the site to be archived at any time between the 1.3 and 1.5 year mark
3. 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
Prepared for Deloitte Canada
Page 32

SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 1.0 Final
Prepared by Radu.Vaduva@microsoft.com
"Document1" last modified on 16 Jul. 14, Rev 2

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 departments 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.
Prepared for Deloitte Canada
Page 33

SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 1.0 Final
Prepared by Radu.Vaduva@microsoft.com
"Document1" last modified on 16 Jul. 14, Rev 2

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:
Prepared for Deloitte Canada
Page 34

SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 1.0 Final
Prepared by Radu.Vaduva@microsoft.com
"Document1" last modified on 16 Jul. 14, Rev 2

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 Comments
Managed Path Y http://msdn.microsoft.com/en-
us/library/bb802766(v=office.12).aspx
Prepared for Deloitte Canada
Page 35

SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 1.0 Final
Prepared by Radu.Vaduva@microsoft.com
"Document1" last modified on 16 Jul. 14, Rev 2

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).aspx
Features 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).aspx
List 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).aspx
Only 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.
Prepared for Deloitte Canada
Page 36

SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 1.0 Final
Prepared by Radu.Vaduva@microsoft.com
"Document1" last modified on 16 Jul. 14, Rev 2

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).aspx
Should 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).aspx
In 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).aspx
No 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.aspx
Visual 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
Prepared for Deloitte Canada
Page 37

SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 1.0 Final
Prepared by Radu.Vaduva@microsoft.com
"Document1" last modified on 16 Jul. 14, Rev 2

is 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).aspx
iFilters are still required for indexing
file types SharePoint doesnt 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.aspx
The 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).aspx
Should 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
Prepared for Deloitte Canada
Page 38

SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 1.0 Final
Prepared by Radu.Vaduva@microsoft.com
"Document1" last modified on 16 Jul. 14, Rev 2

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.aspx
Should 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).aspx
web.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).aspx
Security 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.
Prepared for Deloitte Canada
Page 39

SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 1.0 Final
Prepared by Radu.Vaduva@microsoft.com
"Document1" last modified on 16 Jul. 14, Rev 2

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 departments 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?
Prepared for Deloitte Canada
Page 40

SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 1.0 Final
Prepared by Radu.Vaduva@microsoft.com
"Document1" last modified on 16 Jul. 14, Rev 2

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
Prepared for Deloitte Canada
Page 41

SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 1.0 Final
Prepared by Radu.Vaduva@microsoft.com
"Document1" last modified on 16 Jul. 14, Rev 2

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.
Prepared for Deloitte Canada
Page 42

SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 1.0 Final
Prepared by Radu.Vaduva@microsoft.com
"Document1" last modified on 16 Jul. 14, Rev 2

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
Limitations
Sandboxed 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.
Training
Sandboxed 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.
Prepared for Deloitte Canada
Page 43

SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 1.0 Final
Prepared by Radu.Vaduva@microsoft.com
"Document1" last modified on 16 Jul. 14, Rev 2

Site-collection users with deployment permissions need to be educated (or at least cautioned) about
what types of solutions are appropriate for deployment.
Support
Sandboxed 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.
Performance
Architecting 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 Servers 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.
Prepared for Deloitte Canada
Page 44

SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 1.0 Final
Prepared by Radu.Vaduva@microsoft.com
"Document1" last modified on 16 Jul. 14, Rev 2

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.
Prepared for Deloitte Canada
Page 45

SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 1.0 Final
Prepared by Radu.Vaduva@microsoft.com
"Document1" last modified on 16 Jul. 14, Rev 2

Through the Application Governance and Archiving (AGA) for Microsoft SharePoint add-on,
OpenTexts 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 documents 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 2010s 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
Privacy
Privacy 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.
Prepared for Deloitte Canada
Page 46

SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 1.0 Final
Prepared by Radu.Vaduva@microsoft.com
"Document1" last modified on 16 Jul. 14, Rev 2

Metadata Sharing
Understanding 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.
Performance
Term 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).
Maintainability
In 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.
Extensibility
The 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.
Prepared for Deloitte Canada
Page 47

SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 1.0 Final
Prepared by Radu.Vaduva@microsoft.com
"Document1" last modified on 16 Jul. 14, Rev 2

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
Performance
External systems are great for quickly creating mashups. However, external systems can cause
performance issues through latency.
Security
External 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.
Prepared for Deloitte Canada
Page 48

SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 1.0 Final
Prepared by Radu.Vaduva@microsoft.com
"Document1" last modified on 16 Jul. 14, Rev 2

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
Security
There 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.
Performance
There 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 Modification
Forms 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.
Search
Should a search crawler be allowed to crawl external lists? Depending on the organization, this
might be decided at the list, site, or organizational level.
Prepared for Deloitte Canada
Page 49

SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 1.0 Final
Prepared by Radu.Vaduva@microsoft.com
"Document1" last modified on 16 Jul. 14, Rev 2

Workflows
Workflows 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.
Prepared for Deloitte Canada
Page 50

SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 1.0 Final
Prepared by Radu.Vaduva@microsoft.com
"Document1" last modified on 16 Jul. 14, Rev 2

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 Architecture
Is BCS used within a single farm or across multiple farms?
Line-of-Business (LOB) Integration
BCS 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 Types
Are external content types deployed to production using SharePoint Designer 2010 or Windows
SharePoint Services Solution Package (.wsp) files?
Permissions
What 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:
Prepared for Deloitte Canada
Page 51

SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 1.0 Final
Prepared by Radu.Vaduva@microsoft.com
"Document1" last modified on 16 Jul. 14, Rev 2

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
Prepared for Deloitte Canada
Page 52

SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 1.0 Final
Prepared by Radu.Vaduva@microsoft.com
"Document1" last modified on 16 Jul. 14, Rev 2

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.
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
Prepared for Deloitte Canada
Page 53

SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 1.0 Final
Prepared by Radu.Vaduva@microsoft.com
"Document1" last modified on 16 Jul. 14, Rev 2

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.
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.
Prepared for Deloitte Canada
Page 54

SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 1.0 Final
Prepared by Radu.Vaduva@microsoft.com
"Document1" last modified on 16 Jul. 14, Rev 2

Defined By
Strategy Team, CAS, KMO, future service owners
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 OpenTexts 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.
Prepared for Deloitte Canada
Page 55

SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 1.0 Final
Prepared by Radu.Vaduva@microsoft.com
"Document1" last modified on 16 Jul. 14, Rev 2

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.
When configuring versioning, there are two settings that allow for control of the storage used:
1. The number of major versions to keep
2. 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 Policies
Development 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?

Prepared for Deloitte Canada
Page 56

SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 1.0 Final
Prepared by Radu.Vaduva@microsoft.com
"Document1" last modified on 16 Jul. 14, Rev 2

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 developers 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:
Prepared for Deloitte Canada
Page 57

SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 1.0 Final
Prepared by Radu.Vaduva@microsoft.com
"Document1" last modified on 16 Jul. 14, Rev 2

Setup user
account
The Setup user account is
used to run the following:
Setup
SharePoint Products
Configuration Wizard
Domain user account.
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.
Prepared for Deloitte Canada
Page 58

SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 1.0 Final
Prepared by Radu.Vaduva@microsoft.com
"Document1" last modified on 16 Jul. 14, Rev 2

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 thats 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.
Prepared for Deloitte Canada
Page 59

SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 1.0 Final
Prepared by Radu.Vaduva@microsoft.com
"Document1" last modified on 16 Jul. 14, Rev 2

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.
Prepared for Deloitte Canada
Page 60

SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 1.0 Final
Prepared by Radu.Vaduva@microsoft.com
"Document1" last modified on 16 Jul. 14, Rev 2


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.
Prepared for Deloitte Canada
Page 61

SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 1.0 Final
Prepared by Radu.Vaduva@microsoft.com
"Document1" last modified on 16 Jul. 14, Rev 2

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.
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
Prepared for Deloitte Canada
Page 62

SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 1.0 Final
Prepared by Radu.Vaduva@microsoft.com
"Document1" last modified on 16 Jul. 14, Rev 2

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
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
Prepared for Deloitte Canada
Page 63

SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 1.0 Final
Prepared by Radu.Vaduva@microsoft.com
"Document1" last modified on 16 Jul. 14, Rev 2

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
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.
Prepared for Deloitte Canada
Page 64

SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 1.0 Final
Prepared by Radu.Vaduva@microsoft.com
"Document1" last modified on 16 Jul. 14, Rev 2

Key Considerations
Considerations include:
Should features be deployed to the entire farm or individually (for example, as sandboxed
features)?
Who deploys features?
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.
Prepared for Deloitte Canada
Page 65

SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 1.0 Final
Prepared by Radu.Vaduva@microsoft.com
"Document1" last modified on 16 Jul. 14, Rev 2

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.
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.
Prepared for Deloitte Canada
Page 66

SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 1.0 Final
Prepared by Radu.Vaduva@microsoft.com
"Document1" last modified on 16 Jul. 14, Rev 2

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.
5.2.9 Functional (Unit) Testing
Purpose
User experiences can vary based on user audience and permission level. Its 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.
Prepared for Deloitte Canada
Page 67

SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 1.0 Final
Prepared by Radu.Vaduva@microsoft.com
"Document1" last modified on 16 Jul. 14, Rev 2


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
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:
Prepared for Deloitte Canada
Page 68

SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 1.0 Final
Prepared by Radu.Vaduva@microsoft.com
"Document1" last modified on 16 Jul. 14, Rev 2

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/.
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.
Prepared for Deloitte Canada
Page 69

SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 1.0 Final
Prepared by Radu.Vaduva@microsoft.com
"Document1" last modified on 16 Jul. 14, Rev 2

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.
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
Prepared for Deloitte Canada
Page 70

SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 1.0 Final
Prepared by Radu.Vaduva@microsoft.com
"Document1" last modified on 16 Jul. 14, Rev 2

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
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.
Prepared for Deloitte Canada
Page 71

SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 1.0 Final
Prepared by Radu.Vaduva@microsoft.com
"Document1" last modified on 16 Jul. 14, Rev 2

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
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.
Prepared for Deloitte Canada
Page 72

SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 1.0 Final
Prepared by Radu.Vaduva@microsoft.com
"Document1" last modified on 16 Jul. 14, Rev 2

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.
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.
Prepared for Deloitte Canada
Page 73

SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 1.0 Final
Prepared by Radu.Vaduva@microsoft.com
"Document1" last modified on 16 Jul. 14, Rev 2

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.
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:
Prepared for Deloitte Canada
Page 74

SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 1.0 Final
Prepared by Radu.Vaduva@microsoft.com
"Document1" last modified on 16 Jul. 14, Rev 2

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
a. Helpdesk makes the decision
b. Helpdesk documents all the processes and applications
c. 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 issue
b. Determine whether to go to CAS or development team
c. KMO owns team sites, Gateway
d. Application owners request new features through the Portfolio Management
Service Request process
3. Operations - CAS involved at server down or as decided by KMO
4. 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.
Prepared for Deloitte Canada
Page 75

SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 1.0 Final
Prepared by Radu.Vaduva@microsoft.com
"Document1" last modified on 16 Jul. 14, Rev 2

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.
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 Throttling
The 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 Retention
Retaining 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.
Prepared for Deloitte Canada
Page 76

SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 1.0 Final
Prepared by Radu.Vaduva@microsoft.com
"Document1" last modified on 16 Jul. 14, Rev 2

Logging Database
SharePoint 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 Policies
SharePoint 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.
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.
Prepared for Deloitte Canada
Page 77

SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 1.0 Final
Prepared by Radu.Vaduva@microsoft.com
"Document1" last modified on 16 Jul. 14, Rev 2

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
System Administrators
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:
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
System Administrators
Prepared for Deloitte Canada
Page 78

SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 1.0 Final
Prepared by Radu.Vaduva@microsoft.com
"Document1" last modified on 16 Jul. 14, Rev 2

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)
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:
Prepared for Deloitte Canada
Page 79

SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 1.0 Final
Prepared by Radu.Vaduva@microsoft.com
"Document1" last modified on 16 Jul. 14, Rev 2

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.
The guidance in MOF encompasses all of the activities and processes involved in managing an IT
service: its conception, development, operation, maintenance, andultimatelyits 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 services 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 ITs goals are
aligned with the goals of the organization.
Service management functions (SMFs) support each phase in the process model. Its 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 customers 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.
Prepared for Deloitte Canada
Page 80

SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 1.0 Final
Prepared by Radu.Vaduva@microsoft.com
"Document1" last modified on 16 Jul. 14, Rev 2

Its 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.
6.2 Monitoring SharePoint
To 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 environments 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
Prepared for Deloitte Canada
Page 81

SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 1.0 Final
Prepared by Radu.Vaduva@microsoft.com
"Document1" last modified on 16 Jul. 14, Rev 2

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.
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 its performing.
6.3 Patching and hot fixes
When 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.
Prepared for Deloitte Canada
Page 82

SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 1.0 Final
Prepared by Radu.Vaduva@microsoft.com
"Document1" last modified on 16 Jul. 14, Rev 2

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.
6.4 System Centre Operations Manager (SCOM) 2007
A 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 Service
Project Server Service Project Server Events Service Project Server Queuing
Service
Secure Store Service SharePoint Server Search User Profile Service
Visio 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.
Prepared for Deloitte Canada
Page 83

SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 1.0 Final
Prepared by Radu.Vaduva@microsoft.com
"Document1" last modified on 16 Jul. 14, Rev 2

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.
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
System Administrator
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.
Prepared for Deloitte Canada
Page 84

SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 1.0 Final
Prepared by Radu.Vaduva@microsoft.com
"Document1" last modified on 16 Jul. 14, Rev 2

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.
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.
Prepared for Deloitte Canada
Page 85

SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 1.0 Final
Prepared by Radu.Vaduva@microsoft.com
"Document1" last modified on 16 Jul. 14, Rev 2

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:
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
System Administrator
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
Prepared for Deloitte Canada
Page 86

SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 1.0 Final
Prepared by Radu.Vaduva@microsoft.com
"Document1" last modified on 16 Jul. 14, Rev 2

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
System Administrator
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?
Prepared for Deloitte Canada
Page 87

SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 1.0 Final
Prepared by Radu.Vaduva@microsoft.com
"Document1" last modified on 16 Jul. 14, Rev 2

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 Owners
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.
Prepared for Deloitte Canada
Page 88

SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 1.0 Final
Prepared by Radu.Vaduva@microsoft.com
"Document1" last modified on 16 Jul. 14, Rev 2

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.
Key Considerations
Backup Types
Full backup
Differential backup
Partial backup
Transaction-log backup
Backup Strategy
Full 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 Up
The 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.
Prepared for Deloitte Canada
Page 89

SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 1.0 Final
Prepared by Radu.Vaduva@microsoft.com
"Document1" last modified on 16 Jul. 14, Rev 2

Backup Frequency
Within your backup strategy ,its important to specify how often to back up databases, along with
the backup type that you will use.
Backup Retention
You 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 Snapshots
A 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.
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.
Prepared for Deloitte Canada
Page 90

SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 1.0 Final
Prepared by Radu.Vaduva@microsoft.com
"Document1" last modified on 16 Jul. 14, Rev 2


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.
Prepared for Deloitte Canada
Page 91

SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 1.0 Final
Prepared by Radu.Vaduva@microsoft.com
"Document1" last modified on 16 Jul. 14, Rev 2

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.>>
Prepared for Deloitte Canada
Page 92

SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 1.0 Final
Prepared by Radu.Vaduva@microsoft.com
"Document1" last modified on 16 Jul. 14, Rev 2

7 Training Plan
The 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
Prepared for Deloitte Canada
Page 93

SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 1.0 Final
Prepared by Radu.Vaduva@microsoft.com
"Document1" last modified on 16 Jul. 14, Rev 2

Composites No code solutions using: Visio and Access services,
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-tos and capability reviews. Topics
include:
Document Libraries
Calendar
Slide libraries
Workflows
Microsoft.com
demo and end-
user material
Basic
End users new to
SharePoint
Site Owners new to
SharePoint
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
Prepared for Deloitte Canada
Page 94

SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 1.0 Final
Prepared by Radu.Vaduva@microsoft.com
"Document1" last modified on 16 Jul. 14, Rev 2

Backing up files & content
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
Basic
End users new to
SharePoint
Site Owners new to
SharePoint
A series of articles to address a wide
range of questions and how-tos (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
centeretc.
Microsoft
TechNet
Intermediate
/ Advanced
Developers
Administrators
Microsoft website that provides
overviews, support, and in-depth how-
tos 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
Prepared for Deloitte Canada
Page 95

SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 1.0 Final
Prepared by Radu.Vaduva@microsoft.com
"Document1" last modified on 16 Jul. 14, Rev 2

Governance
Installation
Interoperability
Migration & upgrades
Performance capacity planning
Updates
Content management
Microsofts
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
Prepared for Deloitte Canada
Page 96

SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 1.0 Final
Prepared by Radu.Vaduva@microsoft.com
"Document1" last modified on 16 Jul. 14, Rev 2

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/
Prepared for Deloitte Canada
Page 97

SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 1.0 Final
Prepared by Radu.Vaduva@microsoft.com
"Document1" last modified on 16 Jul. 14, Rev 2

8 Individual Roles and Responsibilities
The 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 team
People
performing
the role
System
Administrator
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
Manage network load Balancing
Operations
Team

Prepared for Deloitte Canada
Page 98

SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 1.0 Final
Prepared by Radu.Vaduva@microsoft.com
"Document1" last modified on 16 Jul. 14, Rev 2

Backup
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
Site-collection policies
Operations
Team

Prepared for Deloitte Canada
Page 99

SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 1.0 Final
Prepared by Radu.Vaduva@microsoft.com
"Document1" last modified on 16 Jul. 14, Rev 2

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
View Reports
Site Settings
Operations
Team
Support Team

Prepared for Deloitte Canada
Page 100

SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 1.0 Final
Prepared by Radu.Vaduva@microsoft.com
"Document1" last modified on 16 Jul. 14, Rev 2

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
Team
Support 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

Program
Management
Responsible for resources and features advocacy.
Deliver solution within project constraints
Coordinate optimization of project constraints
Development
Team

Prepared for Deloitte Canada
Page 101

SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 1.0 Final
Prepared by Radu.Vaduva@microsoft.com
"Document1" last modified on 16 Jul. 14, Rev 2

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
Team
Operational
Team


Prepared for Deloitte Canada
Page 102

SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 1.0 Final
Prepared by Radu.Vaduva@microsoft.com
"Document1" last modified on 16 Jul. 14, Rev 2

9 Governance Tools
This 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.
Prepared for Deloitte Canada
Page 103

SharePoint Server 2010 Operating Model, Deloitte Canada SharePoint 2010 deployment, Version 1.0 Final
Prepared by Radu.Vaduva@microsoft.com
"Document1" last modified on 16 Jul. 14, Rev 2

10 References
Creating your first TFS Build Process for SharePoint Projects:
http://blogs.msdn.com/b/sharepointdev/archive/2011/08/25/creating-your-first-tfs-build-
process-for-sharepoint-projects.aspx
Improving Application Quality Through Testing
http://msdn.microsoft.com/en-us/library/ff650384.aspx
Getting started with development for SharePoint Foundation
http://msdn.microsoft.com/en-us/library/ee539741.aspx
Productivity Hub 2010 End-user training kit that can be installed on SharePoint 2010
http://go.microsoft.com/fwlink/?LinkId=220249
Using features in SharePoint Foundation
http://msdn.microsoft.com/en-us/library/ms460318.aspx

Você também pode gostar