DOAS_Internet_Governance_Plan

SharePoint Governance Plan – DOAS Internet

Georgia Department of Administrative Services







Prepared for

Date & Draft Number







Prepared by

Your Name







Contributors

Revision and Signoff Sheet



Change Record

Date Author Version Change reference



Initial draft for review/discussion









Reviewers

Name Version approved Position Date



Nancy Parrott Portfolio Manager

Daren Duncan IT Manager

Bradley Crowley DOAS SharePoint Administrator

Tammy Strong

Sherman Harris DOAS Security Officer

Ian Thurley









Signoff





Date









Signoff





Date









Page ii

Table of Contents

1 Executive Summary............................................................................................................................. 1



2 Introduction .......................................................................................................................................... 2

2.1 Objectives ........................................................................................................................................... 2

2.2 Audience ............................................................................................................................................. 2

2.3 Scope ................................................................................................................................................... 2

2.4 Risks / Concerns .................................................................................................................................. 2



3 Definitions and Acronyms................................................................................................................... 3



4 Resources ............................................................................................................................................. 4

4.1 Team Roles and Responsibilities ...................................................................................................... 4

4.2 Individual Roles and Responsibilities ............................................................................................... 6

4.3 People .................................................................................................................................................. 8

4.4 Equipment ......................................................................................................................................... 11



5 Governance Hierarchy ..................................................................................................................... 14



6 Operations Policies ............................................................................................................................ 16



7 Application Usage Policies............................................................................................................... 19



8 Communication Plan ....................................................................................................................... 23



9 Training................................................................................................................................................ 24

Training Plan ................................................................................................................................................. 24



10 Support ............................................................................................................................................ 25

Support Plan ................................................................................................................................................. 25



11 Development & Configuration...................................................................................................... 27

11.1 Source Code & Build Control ..................................................................................................... 27

11.2 On-Going Source Code Support .............................................................................................. 27

11.3 Development Standards............................................................................................................. 27



12 Deployment Processes .................................................................................................................. 44



13 Infrastructure ................................................................................................................................... 49

13.1 Site & Platform Classification ...................................................................................................... 49

13.2 Load Balancing ............................................................................................................................ 49

13.3 Environments ................................................................................................................................. 49







Page iii

14 Information Architecture ............................................................................................................... 50



15 References ...................................................................................................................................... 51









Page iv

1 EXECUTIVE SUMMARY

This SharePoint Governance Plan outlines the administration, maintenance, and support of

the Georgia Department of Administrative Services’ (DOAS’) SharePoint Internet

environments. It identifies lines of ownership for both business and technical teams by

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 ensures the system is managed and used in accordance with

its designed intent and to prevent it from becoming an unmanageable system. The

management of an enterprise-wide system involves both a strategic, business-minded team

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 executive leadership and program managers.



The primary goals of the Internet Re-design project are to:

1. Define and document the business requirements of the DOAS program areas and

users of the DOAS Internet site.

2. Develop the physical and informational architecture to support those business needs.

3. Deploy a robust and useable application that will deliver the defined requirements.



The primary goals of this Governance Plan are to:

1. Create the people infrastructure to govern and support the SharePoint Internet

environments.

2. Document initial governing policies and procedures of the SharePoint Internet

environments.

3. Communicate the need for the DOAS organization to provide support via people

resources.



Portal Management

Description of Centralized or Decentralized SharePoint environment – TBD.



Future Direction

It will be the responsibility of the DOAS Governance Team to collectively seek out business

opportunities and user needs for continuous improvement. The team will ask questions such

as:

 How do we identify and develop improvements to business processes?

 What structures need to be in place to deliver this value?

 What areas of DOAS processes require our focus in order to support growth or

change?

 How can we align our activities with the goals of DOAS?

 Are there synergies that can be created between divisions, departments, and other

projects?

 What groups are doing similar initiatives and how can we help?

 In what ways can we reduce inefficiencies and duplication?



DOAS ultimately owns the portal, creating strategic synergies from within and capturing

business opportunities. The IT group facilitates the use of the portal through the

maintenance and administration of SharePoint as an application.







Page 1

2 INTRODUCTION

2.1 Objectives

The primary objective of this Governance Plan is to define a governing body for the usage

and management of the SharePoint Internet portal.

Other objectives are:

 Identify appropriate business owners who are willing to provide insight and

direction for the portal, and are able to drive strategic initiatives into their

respective organizations.

 Identify appropriate infrastructure (IT) resources to provide operational support for

the system.

 Create an effective support system with proper channels of escalation for end

users of the SharePoint Internet environments.

 Communicate the need for DOAS leaders to provide portal content via technically

talented employees both willing and able to use SharePoint in a manner that fulfils

the business needs as identified by DOAS management and the Governance Team.

 Establish initial policies and procedures for using and maintaining the SharePoint

environments.



2.2 Audience

This document is intended to be read by all members of the DOAS SharePoint Governance Team as

well as all key users of the SharePoint environment (IT, business owners, and site administrators).







2.3 Scope

This Governance Plan includes X environments including Dev, Test, Production, etc. - TBD









2.4 Risks / Concerns

The following are risks to the effective execution of a governance plan:

 Inadequate support from the business leaders to affect proper governance

 Administrators or users refusing to, or unable to abide by the given policies in this plan

 Lack of clear policy definition or consistent enforcement.









Page 2

3 DEFINITIONS AND ACRONYMS



A separate document has been created to define the terms acronyms that are used in this

Governance Plan and throughout the SharePoint environment. Organized by intended audience, that

document provides explanations to support the user experience and the technical details needed to

support and modify the system.





Link to the Glossary document here...









Page 3

4 RESOURCES





4.1 Team Roles and Responsibilities

The DOAS SharePoint environments will be managed by two teams: a strategy team and a tactical team.

They will play distinct roles and have distinct responsibilities. For the purposes of this governance plan,

the teams are defined as follows:

Strategy Team

This team consists of division directors and program managers that are willing and able to represent

their respective areas within DOAS, provide strategic insight and direction for the overall portal, and

able to drive strategic initiatives into their organizations. Resources represent a good balance

between business and IT, and also centralized control vs. decentralized empowerment.



Maybe here describe how the managers will be responsible for content within their areas.



Tactical Team

The tactical team consists of four sub teams all charged with supporting the directives of the

strategy team: Operations, Support, Development, and Content.

 Operations: Infrastructure (IT) resources provide operational support for the system as they

help to ensure the enforcement of the governance plan and manage the more routine

maintenance of the system by performing nightly backups, usage monitoring and analysis,

scheduled task validation, and keeping the system current with security releases and system

upgrades.

 Support: SharePoint site owners, system administrators, help desk personnel, and other

various support resources create an effective support system with proper channels of

escalation for end users of the SharePoint environments. This team handles application

questions, bugs, and other problems requiring issue resolution.

 Developers: Technically talented people able to customize, personalize, and use SharePoint in a

manner that fulfils the business opportunities as identified by the strategy team. Skilled

developers will handle large change requests, new features, and program management while

ensuring adherence to standards.

 Subject Matter Experts: Technically talented people able to customize, personalize, and use

SharePoint in a manner that fulfils the business opportunities as identified by the strategy

team. Members can





Strategy Team

Role Provide strategic insight and direction for the portal.

Who* Appropriate managers DOAS-wide representing a good balance between business

and IT, and also centralized control vs. decentralized empowerment.

Responsibilities  Be willing and able to drive strategic initiatives into their respective organizations

 Seek answers to the following:





Page 4

 Are we presenting valuable and needed information to our audience?

 What structures need to be in place to deliver this need?

 What areas of DOAS processes require our focus in order to support

growth or change?

 How can we align our activities with the goals of DOAS?

 Are there synergies that can be created between divisions, departments,

and other projects?

 What groups are doing similar initiatives and how can we help?

 In what ways can we reduce inefficiencies and duplication?





 Visionary – survey the portal landscape, developing and directing its future direction

 Evangelist – serve as cheerleader for the portal technology and what it can do for the business

 User adoption – facilitate user adoption via focused, one-on-one tutorials (primarily with executives who

don’t have time to sit thru training programs), incentive programs (for best collaborative sites, etc), and

feedback surveys.

 Training – as primary trainer for SharePoint, will hold regular training sessions for advanced users and site

administrators.

 Support – serve as top level support for Portal administrators and site administrators (infrastructure support

will be provided by IT).

 Business Analyst and Developer Liaison – meet with business leaders to gather requirements for new portal

projects and manage development efforts of development team.







Tactical: Operations Team

Role Provide operational (IT-related) support and maintenance for the system

infrastructure.

Who Infrastructure (IT) resources.

Responsibilities  Help ensure the enforcement of technical aspects of the governance plan

 Manage routine maintenance tasks such as:

 nightly backups

 usage monitoring and analysis

 scheduled task validation

 keeping the system current with security releases and system upgrades







Tactical: Support Team

Role Provide support of the SharePoint applications to end users.

Who SharePoint site administrators, help desk personnel, and other various support

resources.

Responsibilities  Create an effective support system with proper channels of escalation

 Respond to application questions, bugs, and other problems requiring issue





Page 5

resolution.

 Provide typical SharePoint administration roles such as:

 Provisioning site for end users

 Assigning security permissions to users and groups







Tactical: Development Team

Role Customize, personalize, and use SharePoint in a manner that fulfils the business

needs as identified by the strategy team.

Who This team consists of developers with varying degrees of proficiency in software

development. Members can range from highly skilled programmers to technically

savvy end users in charge of maintaining the SharePoint environment.

Responsibilities  Skilled developers will handle large change requests, new features, and program

management while ensuring adherence to standards.

 Develop customized and personalized solutions for departmental team sites and

divisional portal sites.







Tactical: Subject Matter Experts

Role Develop, approve, and publish content to the DOAS Internet site according to

business needs and audience requirements.

Who DOAS business managers and their designees who can identify needed

enhancements to the areas of the Internet site under their ownership. Members

should have the skills needed to understand and perform basic SharePoint content

activities.

Responsibilities  Monitor DOAS and end-user needs and update site content or request technical

help as appropriate.

 Prepare content (page text, calendars, and documents) for approval.

 Review and approve content prior to publishing to the Internet site.







4.2 Individual Roles and Responsibilities

IT Roles

Role Responsibilities and Tasks Permissions Required Skills Candidate Example

System Responsible for portal Has platform DOAS IT

Administrator infrastructure (hardware, OS, etc) Administrator rights

 Backups / restoration Has site collection

 Collects usage data access

 Manage file size limits or Will have access to







Page 6

Role Responsibilities and Tasks Permissions Required Skills Candidate Example

quotas portal and site

 Initial configuration and configuration settings,

upgrades to OS and WSS but should not make

 Maintains Active any changes without

Directory Site Administrator

 Liaison to Network permission

administration

SQL Administrator /  SQL backups and Has no portal or WSS

DBA restores administration rights

 Monitor performance

and fix issues





SharePoint Roles

Role Responsibilities and Tasks Permissions Required Skills Candidate Example

SharePoint Responsible for global portal and Total access to the Select individuals

Administrator WSS configuration entire portal areas and from DOAS IT

 Disseminate general all sites.

SharePoint info Total access to portal

 SharePoint configuration and site configuration

 Teach SharePoint settings.

 Meet w/ business on Has no system

"how-to" accomplish administrative or SQL

tasks administration rights.

 Manage SP security

 Work with the

Infrastructure Team to

develop infrastructure

and operation best

practices

 Work with System

Administrators to

develop best practices

Web Master / Responsible for portal content. Local WSS site Divisional Lead;

Portal Owner  Manage security collection Communications

 Serves as information administrator. Lead; other high-level

architect to enforce lead

taxonomy standards Typically a Site Owner

 Enforce portal standards with elevated security

(layouts, security rights; a

processes, etc.) Departmental site

 Manage the site layout admin; anyone in the

(look and feel), and company with the

content. required SharePoint

 Provision sub-sites knowledge



Developer Responsible for building the Local WSS site Systems analysis

framework and features of the collection Programming

portal. administrator

 Build the SharePoint look

and Feel

 Modify SharePoint

Templates as Needed

 Build New Web Parts





Page 7

Role Responsibilities and Tasks Permissions Required Skills Candidate Example

 Write ASP.Net Code

 Participate in Design

Tasks as needed

 Participate in

Development and

Testing as needed

Graphic Designer Responsible for building graphical Local WSS site Programming

features of the portal. collection Design

 Modify SharePoint administrator

Templates and Master

Pages as Needed

 Participate in Design

Tasks as needed

 Participate in

Development and

Testing as needed





Business Roles

Role Responsibilities and Tasks Required Skills Candidate Example

Content Manager Responsible for owning and directing a specific piece of the Strategic Departmental head,

portal, relevant to their business unit, department, or team planning, SP team lead, or end

 Responsible for communicating with the business basics user having

to gather requirements and translating them into responsibility of a

business solutions. business problem;

 Content approval typically

 Appoints designated contributor and backup departmental head or

higher.



Contributor Responsible for creating or assembling content (text and SP basics Designee of Content

documents) to be posted to the portal manager

 Submits to Content Manager for approval

 Updates portal pages using available SP methods

and web parts







Legal Responsible for portal and content compliance with legal Knowledge of

mandates. compliance laws

 Assist with compliance policy creation

 Educate users on compliance law

 Audit and enforce compliance.





Reader Internal (DOAS) and external (web) users Read-only access









4.3 People



Strategy Team



Page 8

This small team will provide strategic insight and direction for the portal. A business, technology,

and geographically diverse representation is ideal. Membership is temporary and volunteer.

Region Representing Location Department Contact Contact Email Contact Phone

Country









* Temporary Members, rotated out

∆

Portal Administrator







Tactical: Operations Team

This team will provide operational (IT-related) support and maintenance for the system

infrastructure. Membership is more or less permanent and required.

Region Representing Location Departme Contact Contact Email Contact Phone

Country nt









∆

Portal Administrator



Tactical: Support Team

This team will provide support of the SharePoint applications to end users. Membership by business

owners is semi-permanent; expected, but not required. Regional Support Members and all end

users will rely on business membership.

Region Representing Location Department Contact Contact Email Contact Phone

Country









Page 9

∆

Portal Administrator







Tactical: Development Team

This team will customize, personalize, and use SharePoint in a manner that fulfils the business

opportunities as identified by the strategy team. Membership is assigned by member’s business

unit on either a permanent or ad hoc basis.

Representing Area Contact Contact Email Contact Phone









∆

Portal Administrator









Page 10

4.4 Equipment

The following equipment is subject to this governance plan except where existing IT governance policy

dictates otherwise. In cases of discrepancy, the existing IT governance policy will prevail. Unless

otherwise noted, all equipment is located in Denver, USA where the time zone is GMT -7.

Production Intranet Server Farm

Server Role Server Name (FQDN) IP Address

Web and Search (1)

Web and Search (2)

Index and Job Server

SQL Server 2005 (1)

SQL Server 2005 (2)

SAN Array (1)

SAN Array (2)



Development Environment

Server Role Server Name (FQDN) IP Address

Web, Search, Index, and Job Server

Database Server



Test Environment (Physical & Virtual Servers)

Server Role Physical Server Virtual Server Physical IP Virtual IP

Name (FQDN) Name (FQDN) Address Address









Production Extranet Server Farm

Server Role Server Name (FQDN) Internal IP Address External IP Address

Web/Search/Index/Job Server

Database Server

ISA Server



Plant Windows SharePoint Services Servers

Location Time Zone Server Role Server Name (FQDN) IP Address









Page 11

Location Time Zone Server Role Server Name (FQDN) IP Address









Page 12

Location Time Zone Server Role Server Name (FQDN) IP Address









Page 13

5 GOVERNANCE HIERARCHY

SharePoint Management

The SharePoint environments will be managed via a top-down approach out of three

geographically dispersed regions: North America, Europe, and Asia-Pacific. Environments to

manage will be both IT infrastructure operations and the SharePoint portal application

usage. Each region will have an IT resource and a SharePoint resource. Regions are

ultimately governed by the Portal Strategy Team. Additionally, each site will have its own

local administrator—typically the Plant System Administrator—who will manage SharePoint

locally and escalate issues up to the regional resource as necessary.





SharePoint Governance

The Portal Strategy Team will provide a unified, centrally governed approach to the

SharePoint environments. This team is the overriding authority for all architectural, design,

and development decisions, including all policies and procedures created for the SharePoint

environments. IT will strongly influence foundational and framework-related issues.



Governance will be tightly controlled in areas where there is substantial public exposure in

terms of readership (whether internal or external) or potential litigation issues. In areas

with limited readership or public exposure, governance will be less controlled and allow for a

more de-centralized empowerment of end users. IT will generally defer to the business’

direction or influence for features and content-related issues.



The following areas will be considered by the Portal Strategy Team for inclusion in this governance plan:

 Internal/external users, internal/external data sources, and inputs/outputs

 Personal, team, departmental, divisional, corporate, global considerations

 Parent/child corporations, subsidiaries, and affiliates

 Technologies, processes, logistics, and finances

 Cultural, political, religious, social, economic, and gender forces and influences





How to Get Involved

Employees interested in becoming a member on any of the portal support teams (Strategy,

Operations, Support, or Development) should look for a link on the portal that takes them

to the Portal Governance site. Employees will be able to volunteer their services on this site.

Alternatively, Employees can contact any of the Portal Administrators directly.









Page 14

Governance Model



 Permanent

 Controlled  Dashboards

 Tightly governed  Business Intelligence

 Push content  Business Process Management

 Applications

Corporate

Portal

Divisional Portals





Department and Team Sites  Permanent

 Ad Hoc  Knowledge Management

 Loosely governed  Information Sharing

 Push / Pull content Project Team Sites

 Short Lived

 Collaboration

Personal My Sites



 Permanent

 Personal Information

 Public / Private Views









Taxonomic Section Characteristics Owners







Portal Operations Team

Portal Support Team



Portal Strategy Team



Portal Development Team

Corporate Portal  Permanent

 Controlled; tightly governed  Portal administrators

 Push information to users  Corporate stakeholders

 Dashboards, Business Intelligence, BPM

 Applications, Content

Divisional Portals  Permanent  Portal administrators

 Controlled; tightly governed  Divisional business

 Push information to users owners

 All public sites - content is divisional information

 Dashboards, Business Intelligence, BPM

 Applications, Content

Department and  Permanent and Temporary  Divisional business

Team Sites  Sharing information (push / pull) owners

 Collaboration  Departmental business

 Ad hoc, lax control owners

Project Team Sites  Short lived, timed expiration  Departmental business

 Collaboration owners

 Ad hoc, lax control

Personal My Sites  Permanent  Portal administrators

 Personal info  Employees

 Pull information

 Ad hoc, lax control









Page 15

6 OPERATIONS POLICIES

System Administration



Tasks

Manage SQL Databases and Available Storage Space

Backup and Restoration schedules and audits (list what to backup and where)

Auditing of security logs

Monitoring: Usage analysis and Tuning; automatic monitoring (MOM) and event notifications.

Maintenance of the servers (service packs, etc)

Set and manage quotas for sites

Provide self-support for hardware and software. Where escalation is required, escalate through

normal channels (third party vendors and partners).





Documentation

Document the installation and configuration of the system in its environment. The system must be

documented well enough so as to be reinstalled and reconfigured to last known good operating

standards, should it become necessary to do so.

Document and maintain a document of Scheduled Tasks.

Document the IT Support Team and Escalation points of contact.

Document the installation and configuration of the system in its environment. The system must be

documented well enough so as to be reinstalled and reconfigured to last known good operating

standards, should it become necessary to do so.







Policies

Disaster Recovery

Portal recovery must provide a full recovery from last backup. Recovery of lost sites will be to the

current state of the site at the time the last backup was done.

Regional WSS sites are limited to true disaster recovery (i.e., no item level recovery) until WSS v3.0

is released and implemented.

Hardware

Access to and governance of hardware is subject to existing IT policies.

Hardware will be kept up to date with latest service packs and security updates.

Adhere to policies created by Portal Administrators and the Portal Strategy Team.

The general purpose server should be used for File, Print, and SharePoint only.

Change Management

Communicate with all Portal Administrators any required changes to infrastructure components

prior to performing any changes.

Communicate with all Portal Administrators any proposed changes to the software application,

including custom web applications or web parts.









Page 16

Scheduled Tasks

The system provides for some self-maintenance in the form of scheduled tasks, those tasks that run

automatically and unattended on a routine, scheduled, basis.

There is a need to coordinate the timing of the scheduled tasks to ensure no conflicts of scheduled

tasks.

Scheduled task Schedule

Active Directory imports Nightly

Index replication Nightly

Indexing of content. Various content-dependent

For performance reasons, Europe might index content local to them during schedules during non-business

European night-time. At that same time, the US might index content stored hours.

on European servers. The indexing process would be the reverse during US

night-time.

File System and Database Backups Nightly

Data replication, if needed for disaster recovery purposes Real time



Portal Administration



Tasks

Auditing of indexing logs; search and index tuning.

Monitoring: Usage analysis and tuning.

Policy creation and enforcement

Determine content crawling of regional WSS sites (data sources and crawl schedules)

Assist with determining what data stays local in WSS and what data gets stored on the Portal

Integrate regional WSS locations into Portal

Enforcement of allowable / prohibited file type storage

Perform routine releases and upgrades to the application.

Create site templates for various business scenarios.

Responsible for modifying permissions for portal sites and WSS sites.







Documentation

Document the configuration of the system in its environment such that it could be reconfigured to

last known good operating standards, should it become necessary to do so.

Document the Application Support Team and Escalation points of contact.

Create online documentation for training and support needs. This documentation might include a

listing of FAQs, “how to’s”, and a Glossary of terms.







Policies

Content Management

Content to be published must go through a multi-step approval process to ensure professionalism,

accuracy, privacy, and legal compliance.

Site Provisioning





Page 17

Sites will be created by Portal Administrators.

User Access

Partners, customers, and suppliers must not be able to see confidential data or data intended for

parties of conflicting interest.









Page 18

7 APPLICATION USAGE POLICIES



Policies

Site Provisioning (intranet, extranet, regional vs. corporate, etc.)

Sites should target a specific audience

Employees will be able to create their own My Site and manage sub-site creation in their My Site

up to the 50MB storage quota.

Portal Sites should only be used in instances where:

 Content that applies to multiple parts of the organization is being aggregated and made

available.

 There are resources responsible for maintaining the content on the site.

 The site can be recognized as a top level topic within the organization and is enduring. (e.g.,

Human Resources, IT)

WSS Sites should be used as follows:

 For all document workspaces and meeting workspaces.

 By teams as a method for organizing information that is specific to the team or project they

are currently working on.

Portal Administrators may decide to provision top level sites and grant Business Owners

provisioning permissions (create, administer, delete) over their own sites. Portal Administrators

may need to coordinate and create Project sites since all users may not have access initially;

however, smaller team sites can be created by Site Administrators.

Sites will be created with templates appropriate for their business purpose.

Sites are based on templates that are centrally designed.

The assigned business site administrator is responsible for assigning further access to new sites.

Sites will adhere to the following standards:

 Site owner must be displayed in the top-right corner of each site.

 CompanyX template to be used for all top level sites

 Sub-sites list for immediate (single level) child sub-sites to be displayed under site owner.

Sites requests will list the following as required information:

Purpose

 What is the intention of the site to be created?

 Will it be a Departmental, Project, or Community site?

Value

 How will this site benefit Employees or the business?

Audience

 Who will need access to the site and use the site?

Site Owner

 Who is the person ultimately responsible for the site? This is the Primary Contact.

Site Administrator

 Who will administer and maintain the site? This is the Secondary Contact.

Features

 What are the features needed on the site?

 Document Storage, Newsletter, Calendar, Team Collaboration, etc.

Site URLs will be created according to the standards published in the CompanyX Portal Planning





Page 19

Guide. Briefly, the standards are as follows:

 Divisional Portals – http://division.CompanyX.com

 Departmental & Group Sites – http://CompanyX.com/department

 Team & Project Sites – http://projects.CompanyX.com/project

 WSS Sites – http://team.companyX.com/sites/teamname



Site Management

Site auto expiration: To ensure stale sites are removed and data storage is reclaimed, sites

untouched for 90 days will be slated for automatic deletion. Site owners will be notified if their site

is slated for deletion and provided with a mechanism to remove it from the automatic deletion list.

User Access

All SharePoint Administrators must review the training materials and complete a skills assessment

prior to becoming an Administrator.

Development

There are business-assigned developers. For any development work, contact your business

developer.

Custom development needs to be first scoped by the developer and then approved by Portal

Administrators. This includes any development under Windows Workflow Foundation (WinFX).

No web development tools other than those provided by SharePoint for development of the

SharePoint user interface (no SharePoint Designer, a.k.a. FrontPage, no Visual Studio, no Cold

Fusion, etc). These tools are permissible only for the development of custom web applications

outside of SharePoint. These applications are considered external to SharePoint.

CompanyX Employees must develop web sites in compliance with Intranet design standards and

laws concerning copyrights, proprietary names and trademarks.

Storage Quotas

By default SharePoint imposes a 50MB limit on the size of a single document that can be uploaded

into a document library.

 50 MB of storage is allotted for each user’s My Site.

 100 MB of storage is allotted for all Top-level Team Sites.

 Team Site administrators receive alerts when storage is at 90% of quota.

 SharePoint administrators can override storage quota for Site Collections if necessary.

Document Management

Documents used only by a particular location, or with minimal sharing, should be stored at that

site, typically on that site’s WSS server.

Documents shared across multiple divisions should be stored on the Portal

Allowed file types: doc, xls, ppt, etc…

Prohibited file types: mp3, avi, mdb, etc…

Posting software to the CompanyX Intranet must comply with the rules of software distribution.

(See Policy 846-B, paragraph 7.)

Content Management

All portal content that reaches the portal site is created by a user and then deployed to the portal

via a request to the appropriate content approver or site administrator to add or update the

content on the portal. The administrator may be required to convert some of this content into a

format more suitable for the portal prior to updating the portal site.

Content will be maintained by the appropriate business content owner, typically the author of the

content.





Page 20

Content posted to the Intranet as:

 INTERNAL is not to be transmitted outside the CompanyX Group. Content that is not

identified is considered to be INTERNAL.

 CONFIDENTIAL is not to be transmitted or shared with anyone who does not have

authorization to see it.

 PUBLIC USE has been deemed to not contain proprietary or confidential information and

may be shared with anyone.

 PRIVILEGED is regarded as attorney-client communication and shall be dated and not

transmitted or shared with anyone who does not have authorization to see it.

 COPYRIGHTED shall be assumed to be protected by copyright and shall be dated and

marked. It shall show the copyright owner’s name and shall not be reproduced in electronic

or hard-copy form without authorization.

Users follow a built-in approval process for getting content published to their sites. If the setting is

“automatically approved” the content is immediately available. Where approval is required, the

content must be approved by the appropriate content approver or site administrator. In this case,

the content approver is responsible for reviewing and approving content posted to the Intranet.

Conduct

CompanyX Employees or agents of CompanyX using the CompanyX SharePoint environments are

representing the Company. They are expected to conduct all business in a professional business

manner.







Procedures

How to Volunteer for Governance (Strategy or Support) Teams

 Look for a link on the portal that leads to the Portal Governance site

 Fill out the requested information on this site

 Alternatively, contact any of the Portal Administrators directly

How to Obtain Support

 Contact the site owner listed on the site

 Contact your local System Administrator unless a SharePoint Support Representative has

been designated for your location. In that case, contact your local SharePoint Support

Representative

 Contact a member of your business unit’s volunteer Support Team. Members are listed on

the SharePoint Governance site

 Contact the Portal Administrator for your region (North America, Europe, Asia-Pacific).

Portal Administrators are listed on the SharePoint Governance site

 Contact the Help Desk.

Discover Who is Serving on the Governance Teams

Look for a link on the portal that leads to the Portal Governance site

Requesting a New Site (Site provisioning)

1. Business owner fills out requirements on site request form

 Assign Site Owner and Site Administrator (self or direct report). May be same person.

 Define the Target Audience (e.g., engineering for AOE worldwide)

 Define who (public or only members) has visibility to this content. (Contributors will

appreciate knowing who can see the posted content and determine what is

appropriate).





Page 21

 Define the intended purpose of the site.

 Define value to Employees or business.

 Define features needed.

2. Submit form for approval

 Team Site / Project Site requests are submitted to the Department Owner

 Department Site requests are submitted to the Division Owner

 Portal Site / Community Site requests are submitted to the Portal Administrator

 Extranet Site requests are submitted to the Portal Administrator

3. Site provision request received by appropriate portal, division, or department administrator

4. Request approved or denied with “more info needed”

5. Upon approval, appropriate administrator creates site w/requested template (according to

site type, business purpose, and features).

6. Email is generated and sent to Business Owner that site is available.

Requesting Access To a Site

 Find the site owner listed on the site you want access to.

 Contact that person to request access.

 Alternatively, if the site has Access Requests enabled, simply submit the access request

when presented with that option.

How To Become a SharePoint Administrator

All SharePoint Administrators must review the training materials and complete a skills assessment

prior to becoming an Administrator.



Steps to becoming a SharePoint Administrator of your own site:

1. Download the SharePoint Training Guide here. This is a four part guide. You can download

each part individually or as a complete set.

2. Request a SharePoint Administrator Training Site where you are the Administrator.

3. Read the entire Training Guide.

4. Use your training site to complete the Skills Training section at the end of Part 4 of the

Training Guide.

5. Notify your Portal Administrator when you have completed the skills assessment.









Page 22

8 COMMUNICATION PLAN

Communication to the Business

Communication to the business regarding this Governance Plan will be in the form of web

content on a site off the home page of the corporate portal site. There will be sections on

the page for the following:

Hierarchy of Governance (Summary)

Team roles and responsibilities

Strategy Team

Tactical Operations Team

Tactical Support Team

Tactical Development Team

Individual roles and responsibilities

IT roles

SharePoint roles

Business roles

Current membership of above teams

How to get involved and become a member of above teams

Hardware equipment hosting the SharePoint environments (IT access only)

How to obtain support, by location

Operations Policy (System Administration)

Tasks

Documentation

Policies

Scheduled Tasks

Extranet environment (release 2)

Operations Policy (Portal Administration)

Tasks

Documentation

Policies

Extranet environment (release 2)

Application Usage Policy

Policies

Procedures

Extranet environment (release 2)



Communication to the Governance Teams

Communication to the governance teams regarding this Governance Plan or any governance

activities or issues will be in the following forms:

 Web content listed above

 Scheduled meetings or conference calls

 Ad hoc communications via email.









Page 23

9 TRAINING

Training Plan

For any new system, a solid training plan is required if the users are going to adopt the new

system and use it effectively in their daily activities. Training Requirements are listed below.





Training

All users of the system will require some form of training.

Business Owners need education of 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 individual(s)

 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 WSS deployment

“best practices”).

Refer to the official SharePoint Training Plan for a comprehensive overview of this training.









Page 24

10 SUPPORT

Support Plan

Support for the SharePoint environments is similar to the management of the SharePoint

environments. Support will be provided via a regional, multi-tiered approach. The support

system consists of a network of support professionals: business owners and SharePoint Products and

Technologies experts for first level support, Plant SAs or the CompanyX Corporate Help Desk for tier two

support, and portal administrators for tier three support.

The types of support required for SharePoint Products and Technologies are Operational support (both

back-end system administrator and front-end portal administrator support) and Application Support for

end users.

Who to Contact

Operational Support

Plant SA’s will support the day to day operational issues for their WSS deployments. Infrastructure

issues requiring technical escalation will be escalated to the regional IT contact and subsequently to the

corporate IT contact. Final escalation would be to the appropriate hardware or software vendor.

Service Level Agreements

End User Support

Plant SA’s will be the primary end user support contact for their location until additional Employees are

proficient enough to answer simple end user questions. At that time, Plant SA’s should designate one or

more of these individuals as resident SharePoint Products and Technologies experts to assist with

localized end user support.

At such time as is appropriate, it is intended that the CompanyX Corporate Help Desk assume a role in

the support of end users. End users would first contact their resident SharePoint Products and

Technologies expert. Second tier escalation will be to either the Plant SA or the CompanyX Corporate

Help Desk. Issues requiring further escalation will be escalated to the Regional Portal Administrator.

Final escalation would be to the appropriate software vendor.

Support Availability

Support Group Special Functions Availability

User Self Help  Online information on the Corporate Intranet 7 days x 24 hours

 Default SharePoint Products and Technologies

help documentation

 Select Site Provisioning, including My Site

Tier 1  Basic product support; general how to and 7 days x 24 hours

 Business owners troubleshooting questions from users

 SharePoint Products  Escalations to tier 2

and Technologies

experts

 Corporate Help Desk









Page 25

Tier 2  Provide routine tasks to users such as fulfilling Normal localized

requests for site provisioning of team sites business office hours

 Plant SAs

 Corporate Help Desk  Site access issues

 Change site ownership Corporate Help Desk

is available M-F from

 Increase storage quota 8:00 AM – 5:00 PM

 Escalations to tier 3 MST (GMT -7)

Tier 3  Create or delete portal sites M-F from 8:00 AM –

 Portal Administrators  Redirect or rename site 5:00 PM within each

 Regional System  Site restore requests of the three regions

Administrators  Resolve escalated issues

Sample Availability Schedule

Notice that many locations will receive support outside the hours of 8 am – 5 pm due to their

relation to their Portal Administrator’s time zone. No direct support coverage will be available for

users between the hours of 2 am – 8 am MST.

Location North America Europe Asia-Pacific

Time Zone Denver, USA Europe China, Singapore

GMT -7 GMT + 1 GMT +8

Denver, USA GMT -7 8 am – 5 pm 4 pm – 1 am 11 pm – 8 am

Europe GMT +1 12 am – 9 am 8 am – 5 pm 3 pm – 12 am

China GMT +8 5 pm – 2 am 1 am – 10 am 8 am – 5 pm

Singapore GMT +8 5 pm – 2 am 1 am – 10 am 8 am – 5 pm

Asia-Pacific will be supported by Singapore and China. Hours of support are below.

India GMT +7 7 am – 4 pm

Japan GMT +9 9 am – 6 pm

Korea GMT +9 9 am – 6 pm

Dandenong, Victoria GMT +10 10 am – 7 pm

EU could support Eastern US’s evening hours in their morning and Western AP’s morning hours in their

evening, but for simplicity’s sake, we will keep support within geographical regions. If it becomes necessary in

the future to offer more comprehensive support hours, we will consider revising this policy at that time.





Tier 1. Local SharePoint Products and Technologies experts, business owners, and the Corporate Help

Desk are the first line of contact for all users with questions and problems concerning the SharePoint

environments. Support staff help users validate issues, understand features and functionality, resolve

known issues and escalate issues that require additional expertise or back-end administrative access to

the SharePoint Products and Technologies application or hardware. Help Desk technicians have

SharePoint Products and Technologies experience and receive advance training prior to end users.

Tier 2. Plant SAs and Corporate Help Desk Technical Support staff comprise tier 2 support and have two

roles in assisting users with SharePoint Products and Technologies issues. First, tier 2 staff validates

issues and reviews steps taken by tier 1 support to make sure no troubleshooting steps were missed.

Second, tier 2 staff has administrative access to SharePoint Products and Technologies and resolves

common issues that require administrative access such as quota increases or change of team site owner.

Tier 3. Portal Administrators and regional System Administrators with extensive SharePoint Products

and Technologies experience, including those involved in the design and architecture of the system,

provide tier 3 support. Tier 3 support is expected to comprise approximately 1 to 2 percent of support

calls.









Page 26

11 DEVELOPMENT & CONFIGURATION

11.1 Source Code & Build Control



11.2 On-Going Source Code Support



11.3 Development Standards

 MOSS 2007 development includes development of Web Parts, custom

workflows and custom list and site templates.

 Alternatively, other types of modifications can include branding and

integration with back-end LOB applications by using Microsoft Office

SharePoint Designer 2007.

 These two types of development tasks are differentiated by classifying the

former as assembly-based development and the latter as artifact-based

development.

 The method a single developer uses to approach his or her development is

much different from the approach a team takes to collaborate and develop a

SharePoint Server solution.



 Similar to traditional ASP.NET or Windows Forms development, a single

developer often has the flexibility to control all aspects of the project. While a

single developer can employ source control as a best practice, the team

dimension of development is not present. When attempting to conduct team

development, however, you require a valid source control system, along with

coping and an understanding of locking, versioning, workspaces, and other

concepts related to shared development.



 Enterprise source control products, such as Microsoft Visual Studio Team

System and Microsoft Visual Studio 2005 Team Foundation Server, provide

an excellent and scalable environment that allows for the holistic

coordination of team development efforts.



 However, with solution development in SharePoint Server, the

aforementioned types of development often are outside the normal

considerations for a team's traditional application development.



 Enterprises must consider and attempt to construct a team-environment

model that accommodates the requirements for SharePoint Server

application development.



 To construct a valid team model for development using the SharePoint

Server platform, SharePoint Server includes both assembly development and

artifact development. As shown in Figures 1 and 2, assembly and artifact

development contain separate types of entities, outputs, and actions. As







Page 27

such, each demands a different approach to development, especially for a

successful collaborative team development effort.

Figure 1









Figure 2









Assembly Deployment



 Assembly development for SharePoint Server is similar to traditional

application development. In this branch of solution development, developers

should use Visual Studio 2008 to create various assemblies that are

registered with the SharePoint Server Web application registered with the

SharePoint Server Web application and alternatively placed into the global

assembly cache.







Page 28

 These assemblies function as an extension to a Web application. Assemblies

are usually in the form of Web Parts (essentially, ASP.NET 2.0 Web Parts) or

other shared libraries that can service other assemblies.



 Assembly development encompasses solutions built using the Visual Studio

2008 Extensions for Windows SharePoint Services and includes custom list

definitions, site definitions, and a specific SharePoint Web Part project type.



 Assembly development for SharePoint Server is directly compatible with

traditional models of team development. Recently, team development for the

Microsoft .NET Framework and other Microsoft technologies has migrated

toward a model that supports collaboration and development by using

isolated development environments. Developer code changes are combined

through a common source control repository and build process.



 The specifics of outlining a typical team member’s working environment and

the overall assembly development process for SharePoint Server are shown

in the following figure 3.









Page 29

Fig 3.Recommended assembly development environ 1









Individual Development Environment



 The diagram in Figure 3 outlines the proposed configuration for

individual assembly development on the SharePoint Server platform.

 Conforming to the team model of collaborative development controlled

through island workspaces, the developer’s local computer

environment uses virtualization technology to facilitate development

against an authentic SharePoint Server instance. In this configuration,







Page 30

the developer actually conducts solution development within the

Microsoft Virtual PC running SharePoint Server 2007.

 Developers must have their own virtual computers running SharePoint

Server 2007 to use during application development.

 Developers can choose to run Virtual PC 2007 or Microsoft Virtual

Server 2005 R2.

 The interaction between the development environment and the source

code repository takes place from the within the virtual computer. The

following are two preferences of source controls

o Microsoft Visual Studio 2008 Team Foundation Server

o Microsoft Visual SourceSafe

o SubVersion (SVN) Control

 This configuration provides the developer with a SharePoint Server

2007 server to conduct development, deployment, and testing of

assemblies such as Web Parts, SharePoint Server object definitions etc

without interrupting or infringing upon the efforts of other developers

working on the overall solution.

 An alternative configuration is to maintain a SharePoint Server 2007

virtual computer and conduct coding within the developer’s physical

computer (the host with respect to the guest SharePoint Server 2007

virtual computer). Developers can then choose to deploy to their own

SharePoint Server 2007 virtual computers. This configuration requires

that the SharePoint Server 2007 virtual computers maintain network

access.

 Additionally, in the depicted configuration, the virtual computers must

have the Visual Studio Team System Team Client installed and be able

to connect to the Team Foundation Server.

 To conduct authenticated access to Team Foundation Server

resources, the virtual computer containing the individual developer’s

SharePoint Server 2007 environment might need to be part of the

same domain as the Team Foundation Server, or alternatively the

virtual computer can belong to a special domain with trusted

relationships to the domain that contains the Team Foundation Server.

 After the development environment is established, Team Foundation

Server workspaces are created locally and collaborative development

can begin using Team Foundation Server as the centralized source

control and work item tracking platform.

 The development team can collaboratively engage in test-driven

development, implement agile Microsoft Solutions Framework

methodologies, and work toward developing a common set of

assemblies for SharePoint Server solutions while preserving the

integrity of its own isolated development environment. This



Page 31

configuration allows for maximum independent productivity while

preserving a single code base using Team Foundation Server.



Assembly Deployment Model for SharePoint Server

 The assembly deployment model for SharePoint Server is based on taking

assemblies from a build environment, packaging those assemblies into a

release vehicle (Microsoft Installer or SharePoint Server solution), and

installing them on an integration environment where the various bits are

tested. The following figure outlines a process in which the release manager

takes a build of the assemblies and migrates them to the integration

environment









Page 32

Fig 4.Integration server deployment process 1









Page 33

 The integration environment is one in which the SharePoint Server structure

and taxonomy ideally mirrors the configuration of the developer’s

environment. The release manager installs the assemblies into the shared

integration environment.

 This environment provides a place for integration and systems testing. In this

environment, each assembly is tested to ensure that it not only passes the

required unit tests, but also integrates correctly with other assemblies

developed as part of the SharePoint Server solution, and operates as

expected within the SharePoint Server environment.

 The strength of SharePoint Server solutions as a deployment vehicle is the

fact that they can be installed on a server farm and then deployed

automatically to other farm front-end Web servers. A SharePoint Server

solution is cleanly installed and managed (uninstalled, deactivated, and so

on) using Central Administration.

 However, we can capitalize on Microsoft Installer (.msi) files to provide

custom installer actions and process wizards that can address very complex

installation requirements.

 The diagram in Figure 5 shows the migration of code directly from a

developer’s SharePoint Server 2007 environment. In this diagram, there is

no build server to pull code from and the assumption is that the developer’s

SharePoint Server 2007 environment is the release manager’s workstation.

 This diagram assumes that the release manager pulled the documents from

source control against a label, and is using his or her local computer as a

manual build and package environment.

 In a more refined and process-driven team development environment, Team

Foundation Server can be used to conduct the check-out and build process,

as depicted in the following diagram.









Page 34

Fig 5.ntegration server deployment process us 1









 In the model in Figure 5, following the check-in of the assembly code into

Team Foundation Server from the developer’s virtual MOSS environment, a

lead developer or other team member reviews the check-in and labels the

project.

 During a nightly build (or continuous integration) process, the source code is

checked out, compiled using the Team Foundation Server build server

capability, and deposited in a network share that is available to the release

manager.

 Optionally, during each build process, the build server can execute a

specified set of tests established during the build server configuration for this

team project. At this point, the release manager can choose to package the

build output using the desired vehicle and deploy it to the integration

environment for testing



Page 35

Artifact Development

 The development of items relating to the look and feel of a SharePoint site

often relate directly to the development of items such as master pages

and style sheets. These objects are considered artifacts in that they are

not typically compiled and deployed as assemblies.

 These artifacts are characterized as content items that fit into the

SharePoint site structure and that are applied at run time for the

SharePoint Server site.

 The primary tool to create and manage these artifacts is Microsoft Office

SharePoint Designer 2007. While Visual Studio has capabilities to assist

developers in the creation and modification of these items, Office

SharePoint Designer has new design-time tools and capabilities to help in

the authoring and rendering of the artifacts so that their appearance

during design time is extremely similar with the way the items will look

after they are published and deployed.

 The challenge with these Office SharePoint Designer artifacts is to

determine the best method to conduct team development, testing, and

deployment. To address this challenge, you need an understanding of the

development model for SharePoint Designer and the differences between

artifact and assembly development.





Differences between Assembly and Artifact Development

 One of the primary differences between assembly development and

artifact development is that SharePoint Server contains a facility for built-

in source control as part of its Web publication and approval functionality.

 In contrast, assembly development relies on an external, server-based

source control environment.

 The functionality in SharePoint Server provides source control-like

functions that allow content approvers to visually inspect a site and its

changes before they become visible to the user community. This

functionality is considered traditional content development.

 It is critical to understand that content development is very different from

traditional development. While content development contains changes to

pages, styles, master pages, and layouts, as well as changes to site

content itself, the place in which these changes are made actually should

be construed as a production environment. The organization provides the

ability to conduct content or artifact development within its live

environment and approve or reject changes, or the organization specifies

whether an authoring environment is provided that sends content to a

production environment.





Page 36

 In both cases, the hardware and environments in which content is

developed is considered production (that is, production content

development environments for business users to develop and deploy

content and a production content rendering environment).

 For SharePoint artifacts, these items are considered content. They are

stored within the SharePoint Server content database and are subject to

publication and approval. Because these items are considered content

instead of programmable assemblies, you can make observations about

the team development process with regard to items designed by using

SharePoint Designer.

 The following diagram depicts some of the differences between content or

artifact and assembly development.









Page 37

Fig 6. Assembly and artifact development proc 1









 Figure 6 shows the two-dimensional process of overall solution development

for SharePoint Server. The vertical assembly deployment process is depicted

by the movement of code (assemblies developed in an isolated environment

according to the process of team development) as it is compiled, packaged,

and deployed between development, integration, and production

environments.

 The horizontal process outlines how the production of content occurs on

production-classified hardware. Where assembly development is literal

environment migration between specified server environment boundaries

(physical development, integration, and production servers), the



Page 38

development of content is more logical and can even take place within a

single production SharePoint Server environment



 In Figure 6, content developers, using SharePoint Designer, create master

pages, alter and create style sheets, develop site content, and even create

new pages. Because this is all content authoring, the draft and finalization of

the changes (the development) go through the SharePoint Server Web

content publication process.



 This process can occur within a single production environment. Alternatively,

and as shown in Figure 6, the approved and published content and

SharePoint Designer artifacts can then be deployed automatically to a view-

only production environment via a content management path established

between the two environments



 Based on these differences, the following guidance can assist in the

organization of team development regarding SharePoint Designer artifacts

and other content





During the SharePoint Server solution development process, establish an authoring

environment where the following is possible:



 Content developers can use SharePoint Designer to create and modify content

(master pages, custom pages, style sheets, and so on) within a mirrored site collection

that actually represents the production environment.



 Authoring activities make use of SharePoint source control and publication features.



 Content developers have the ability to modify the existing production environment

and conduct publication using a content management path to the production Web farm.



 A production-class environment is provided by the authoring environment, such that

all assemblies, Web Parts, SharePoint Server solutions, and structural changes that are

deployed to the production Web farm are also deployed to the authoring environment.



 The authoring environment can exist within the production environment as the

SharePoint Server Web content publication feature provides a level of abstraction

between proposed changes to content and approved changes.



 From a team perspective, the shared authoring environment is more effective than

individually separate authoring environments.







Page 39

 SharePoint Designer artifacts do not need to be integrated with enterprise source

control.



 Enterprise source control (such as Team Foundation Server) should be used strictly

for assembly development in a team environment, while the effort to integrate content

management items into source control is not a supported process.



 Attempts to integrate items into enterprise source control that are considered

SharePoint Designer content items and part of content development require extensive

workarounds involving manual processes and procedures.



 Items built into SharePoint Designer as content are subject to the Web publication

process of source control, approval, and publication.



 Use content management paths to publish SharePoint Designer changes to

production environments.



 Make content management paths the primary vehicle of choice to send content

designed with SharePoint Designer between authoring environments and their content

counterparts.



 While import and export of site content to .fwp packages from SharePoint Designer

achieve the same function, ensure that content management paths present a less

procedural and more reliable method of moving content between SharePoint Server

environments.



 A significant difference between assembly and artifact development relates directly

to how the physical coordination of multiple developers conducting simultaneous

content development is achieved.



 The guidance to establish a single authoring environment for multiple content

developers is particularly significant. The reasoning behind this concept is that the

migration and merging of master pages, style sheets, and other content objects can be

extremely problematic.



 SharePoint Server does not have a direct method of conducting merges between

these objects, as they are considered content, not code. Additionally, moving these

items among multiple authoring environments is extremely difficult to manage and

coordinate for multiple team members.









Page 40

 Thus, a single authoring environment where multiple content developers can use

SharePoint Designer to create and publish content simplifies time spent in migrating

content artifacts from separate environments into a production environment.



 The direction to avoid integrating content artifacts with enterprise source control is a

significant departure from assembly development as well. The requirements of

accommodating these items by extracting them from the SharePoint Server content

database through SharePoint Designer and including them in source control would be

overly procedural and subject to error.



 Manually compiling the items in source control though inclusion in a Visual Studio

project requires intensive procedural planning and discipline to follow, and does not

represent the intended design-time experience for SharePoint Designer content

development.



Webparts and Field Controls in page layouts



When creating editable content regions on a page layout, enabling content owners to add

and manage their own content, developers/designers are presented with two options:

field controls or Web Parts. These two options are very different and Publishing site

developers should be aware of the differences. The fundamental difference comes down

to where the data is stored.



Web Parts



Web Parts come straight from ASP.NET and their data is stored in a personalization store.

Microsoft was nice and baked the personalization store into the site collection's content

database. Data in a Web Part is stored within the context of the PAGE (ie: URL) & the

user (which could be the shared user or a specific person). This does allow the content in

Web Parts to be uniquely personalized by authenticated users.



In addition, developers and designers can only create Web Part Zones on the page layout.

Content owners can then put any Web Part in the zones and any content within them.



Field Controls



Field Controls are much different from Web Parts. They are more like windows into list

items. A field control pulls data (in display mode) from a particular column in a list item

and writes back to that column in edit mode. Pages in a Publishing site are stored as

items in a list; the Pages list. Because they are in a list, they can leverage all the benefits

a list has to provide, but visioning & history is the most important here. Just keep one

thing in mind: field controls are simply gateways, or windows, to the data.



When a developer places a field control on a page layout, they have the ultimate control

of where it is placed on the page and any rules such as if the content owners can insert

tables or images into the content. The content owners can only work within the rules

defined by the developers.



What is the significance?





Page 41

Great question! From my experience, MOST customers (90%+) who are rolling out a

Publishing site, or Web-based content management systems such as MOSS 2007 WCM,

are doing so because the following aspects are important to the project:



 Consistent look and feel (aka: a corporate brand)

 Empower content owners & subject matter experts (SME) to maintain the content

 Free up IT staff from updating content submitted by SMEs

 Structured organization of content and a versioned and/or historical record of the

content



The challenge here is that Web Parts pose a problem with this approach. Because their

data is stored in the ASP.NET personalization store in the context of the page (it's URL

mind you) & the user. However with field controls, the data is saved with the page's list

item. This means that when the page is updated, a new version is created and the old

data is retained with the page.



Another challenge is with URLs in the content... especially relative URLs. Take the

Publishing HTML field type & the Content Editor Web Part (CEWP). The CEWP does not

store relative URLs... it stores only absolute URLs. Even if you enter a relative URL into

the editor, it will be converted to an absolute URL. The rich text editor the Publishing

HTML field type is tied to does not convert relative URLs to absolute ones.



If structure and history is important on your site, you should ONLY consider field controls

for your content. If you want to have a more relaxed authoring environment where

structure & history isn't important, Web Parts are better. What if structure & history is

important... does it ever make sense to use Web Parts? Sure! Use them for providing

functionality like stock quotes, consuming news feeds, or rolling up content (as in the

Content Query Web Part). In this scenario, the only data that's stored is configuration

data... not true content.



To summarize: the content in Web Parts is not versioned and there is no history,

but the content in field controls is versioned & a history is retained (provided the

Pages library has visioning enabled, which it does by default).









Page 42

Page 43

12 DEPLOYMENT PROCESSES

In a nutshell, Content deployment is the copying of content from one site collection to

another, either within the SharePoint farms or across farms. The most common scenario that

content deployment targets Is that enabling content authoring (a read/write environment)

within the internal network and content delivery to the internet.

Once configured by the administrator, content deployment can take place without manual

intervention.

While the main application for content deployment is publishing sites, it can also be used with

intranet sites and for deploying content across site collections on a single machine running

MOSS. More complex uses include a three-tier deployment topology (authoring, staging and

production).

Content deployment also features a capability called Quick Deploy that enables content

authors to deploy single pages from within the authoring environment without having to wait

for the next scheduled content deployment job to run.

Content Deployment is always one way from source to destination; it does not provide

replication or synchronization capabilities. Administration of content deployment

configuration and operations takes place within SharePoint Central Administration and

therefore requires SharePoint farm administrator rights.

Content deployment operations cannot be delegated to a subset of users, as is the case of

many of the Shared Service Providers (SSP) features.

By default, content deployment is incremental; it will deploy only the changes since the last

successful deployment. This approach avoids unnecessary processing and bandwidth. If a full

deployment is required, it can also be configured.

Content deployment deploys the most major version and minor versions of the content item.

For example, if version 2.7 of a page is being deployed, the most recent major version of the

page, along with the most recent minor version (2.7), will be deployed to the destination.

A destination site collection for the content deployment must be based upon the Blank Site

template. Dependencies of the content deployment are picked up and handled by content

deployment as long as those dependencies reside in SharePoint content database.

Content deployment also handles the activation of already deployed features in the

destination.





Paths

 To be created by Administrators

A content deployment path defines a relationship between the source and destination site

collection for the purposes of content deployment. A path contains the details of both the

destination and source web application and site collection. In addition, authentication details

for the destination are necessary in order to connect and select the destination site collection.

The application pool identity of Central Administration Web application can be used or

alternative credentials can be specified using either windows or basic authentication. A path

can also be configured to deploy user names associated with the source content, and

related security information, such as ACLs, roles and membership, if desired.









Page 44

A path itself does not perform any deployment of content; it is purely the mapping, or link,

between the source and destination servers. Once paths can be created and configured,

jobs can be associated with a path to begin deploying content.

Jobs

 To be created by the administrator

Once a path is defined, a deployment job can be created and associated with a path. A job

defines which sites within the source site collection are to be deployed, and the schedule

indicating when to run the job. The job also specifies whether to deploy all content or just

content that has been added or changed since the last time it ran(incremental deployment).

When configuring a job, e-mail notifications can also be specified to indicate deployment

success or failure. Jobs provide the capability to deploy content updates on a regular

scheduled basis without the need for manual intervention.

A given path can have many jobs associated with it, each with its own schedule and

configured to deploy specific sites within the source site collection. This granular control

enables a common scenario whereby particular sections of a Publishing site have more

aggressive deployment schedule than others.

Quick Deploy Jobs

. To be used by Content authors

Because Content deployment is managed via Central Administration, it requires Central

Administration privileges. This is entirely appropriate for the initial configuration and ongoing

management, but it does not address the need for content authors to be able to deploy certain

pieces of content in an “on demand” fashion without having to wait for the next scheduled

deployment to occur. This requirement is met by the Quick Deploy function.





Once the path is created , a Quick Deploy job for the path is automatically created. However,

the Quick deploy job must be enabled before site owners or members of the Quick Deploy Users

group can take advantage of the feature(the Quick deploy option is grayed out with the Page

editing tool bar). To configure the Quick Deploy job, choose Quick Deploy Settings from the Ite

menu on the Manage Content Deployment Paths and Jobs page. The Quick deploy feature

executes on a configurable schedule, which is set to every 15 minutes by default. The Quick

Deploy job checks the Pages library for items that are marked by deployment since the last time

it ran and then deploys these items.

By default, only site owners, can mark pages for deployment using Quick deploy. However sites

that have the Office SharePoint Publishing Infrastructure feature enabled include a Quick

deploy Users SharePoint group, and members of this group(commonly content authors) can

mark page fir deployment using the Quick deploy item for the Tools menu within the Page

Editing Toolbar.

If a path is created within the site collection before the Publishing Infrastructure Feature is

enabled, the Quick deploy job will not be created. To make use of Quick Deploy, delete and

recreate the path after the Publishing Infrastructure Feature has been enabled.

Design Constraint

MOSS 2007 has a design constraint, if a new page is created within the top-level site and a new

page is created within the News site, and then the News Job is rerun, the new page within the

top-level site is also deployed. This is a known issue, with content deployment that means that

content that’s changed within the top-level site is always changed, regardless of which jobs are







Page 45

run. It is necessary for the capabilities of the top-level sites to be the same on both the source

and destination; therefore, content deployment checks this every time a job is run.





Deploying of Features and solutions.

Features facilitate much more code reuse and provide developers with an easy way to not only

introduce new and updated components and functionality into exisiting SharePoint sites, but

also to empower site owners and administrators to implement it without developer involvement.

The solution framework provides developers and administrators with a way to easily deploy

custom code and files throughout a SharePoint implementation, including a SharePoint farm

containing multiple servers such as a load-balanced Web Front-end (WFE) servers.

Once the feature has been created, it then needs to be activated. The activation of a feature is

dependednt upon the defind scope of the feature. When a feature is activated, SharePoint

performs the work defined in the feature. This activation and deactivation of feature provides

administrators and developers with the capability to toggle functionality on or off with ease via

the browser interface.

The following table shows the webparts and how they will be deployed.



Type Technique Languages Editor Deployment comments

technique



Customized Convert list view XML/XSL SharePoint Manual, Feature

webpart to dataview Designer



Client-side Content Editor, HTML, Browser Manual, Feature

webpart XML Viewer, Javascript,

PageViewer XML\XSL



Hosted Build C# Visual Studio Solution

Webpart UserControls

and load them

in SmartPart



Rendered Write code C# Visual Studio Solution

Webparts based on the

Webpart class



Global Page Build ASP.NET C# Visual Studio Features,

web page and Solutions

deploy to

_layouts







The first two techniques can be deployed manually such as exporting a webpart and

importing it or can be deployed as a feature. If there is a need to access the database,

SharePoint, Active Directory, or other objects on the server, you’ll need to use hosted, rendered

or global page approach.

Hosted Web Parts

Hosted Webparts are based on Smart part, which loads ASP.NET User controls (ascx) into

SharePoint. Usercontrols are developed visually out of ASP.NET built-in controls. It’s a easy way to

migrate existing ASP.NET applications to SharePoint using this approach. We deploy the hosted

webparts as solutions using stsadm.exe command line tool.





Page 46

Rendered Web Parts

Are written entirely in code – there is no visual designer. They are based on the new ASP.NET

Webpart class, which renders the component controls. They are harder to write than the hosted

webparts but are easier to deploy to multiple servers. This is the technique that commercial

webparts use. We deploy the hosted webparts as solutions using stsadm.exe command line tool.

Global Pages

Are ASP.NET Pages deployed to the _layouts folder on the SharePoint server. Pages in that folder

are availale to all the sites, which as the MyInfo.aspx page used by the site Aggregator web

part. They are deployed as features using the STSADM command line tool.









Page 47

13









Page 48

14 INFRASTRUCTURE

14.1 Site & Platform Classification



14.2 Load Balancing



14.3 Environments

Security









Page 49

15 INFORMATION ARCHITECTURE









Page 50

16 REFERENCES

SharePoint Training Plan









Page 51