ESSENTIALS OF A SUCCESSFUL SHAREPOINT DEPLOYMENT
SHAREPOINT DEPLOYMENT
GUIDE AND CHECKLISTS
checklist-front.indd 1 10/23/2007 5:09:30 PM
Front Side
SHAREPOINT FEATURE AREAS
SAMPLE HIGH-LEVEL DEPLOYMENT PLAN
SHAREPOINT GOVERNANCE CHECKLISTS
Information Architecture
Project & Operational Management
Development & Confi guration
Infrastructure
Testing & Provisioning
Operational Concerns
Education & Training
Taxonomy & Navigation
Enterprise Search
SHAREPOINT RESOURCES
Reverse Side
GOVERNANCE TIPS AND MORE INFORMATION
STEPS TO A SUCCESSFUL MANAGED DEPLOYMENT
SHAREPOINT GOVERNANCE PLAN: INTRANET MODEL
SHAREPOINT PHYSICAL TOPOLOGIES
SHAREPOINT CONTAINMENT HIERARCHY
SHAREPOINT DEPLOYMENT TEAM ROLES
MICROSOFT OFFICE SHAREPOINT SERVER 2007
DEPLOYMENT GUIDE AND CHECKLISTS INDEX
checklist-front.indd 2 10/23/2007 5:09:33 PM
MICROSOFT
OFFICE SHAREPOINT
SERVER 2007
FEATURE AREAS
Business
Intelligence
Collaboration
Business
Forms
Portal
Content
Management
Search
Platform
Services
WINDOWS SHAREPOINT
SERVICES 3.0
SHAREPOINT SERVER
2007 STANDARD
SHAREPOINT SERVER
2007 ENTERPRISE
COLLABORATION
Docs/tasks/calendars, blogs,
wikis, e-mail integration,
project management “lite”,
Outlook integration, offl ine
docs/lists
PORTAL
Enterprise Portal template,
Site Directory, My Sites, social
networking, privacy control
BUSINESS INTELLIGENCE
Server-based Excel
spreadsheets and data
visualization, Report
Center, BI Web Parts, KPIs/
Dashboards
PLATFORM SERVICES
Workspaces, Management,
Security, Storage, Topology,
Site Model
SEARCH
Enterprise scalability,
contextual relevance, rich
people and business data
search
BUSINESS PROCESS
MANAGEMENT WITH WEB-
BASED FORMS
Rich and Web forms based
front-ends, LOB actions,
pluggable SSO
CONTENT MANAGEMENT
Integrated document
management, records
management, and Web
content management with
policies and workfl ow
checklist-front.indd 3 10/23/2007 5:09:36 PM
ENVISIONING
• Evaluate Microsoft Offi ce SharePoint Server 2007 features
• Formulate preliminary cost/benefi t analysis
• Determine project scope (lab, pilot, international/regional
deployment, coexistence strategies, etc.)
• Secure executive sponsorship and funding
PLANNING
• Assemble Project Teams, Defi ne Roles
• Review/Detail Technical Requirements
• Review/Detail Preliminary Enduser and Business Requirements
• Determine Preliminary Design Objectives
• Identify Coexistence Strategies
• Establish Test Lab Environment
• Perform Risk Assessment
• Defi ne Communication Strategy
• Defi ne Education/Training Strategy
• Review Client Software and Hardware
• Create Governance Plan with Mission, Vision, and Strategy
• Plan Server Confi guration
• Plan Security
• Plan for performance
• Plan for network upgrades and WAN considerations
• Plan for failover and disaster recovery
• Plan for Localization
SAMPlE DEPlOYMENT PlAN (1)
checklist-front.indd 4 10/23/2007 5:09:37 PM
PLANNING (continued)
• Plan Integration
• Determine need for WSS, MOSS 2007 Standard or Enterprise
• Plan Collaboration Solutions
• Plan Enterprise/Web 2.0 Wikis and Blogging
• Plan Document/Records Management
• Plan Indexing/Search Center & Best Bets/Keywords
• Plan Portal
• Plan Scorecards
• Plan Web Content Management
• Plan Workfl ows
• Plan Internet Site
• Plan Extranet Partner Solution
• Plan Forms Solution
• Plan Excel Services, KPIs, Reporting Center
• Plan Maintenance
• Plan Content and Navigation Structure
DEPLOYMENT, IMPLEMENTATION, & CONFIGURATION MANAGEMENT
• Deploy Pilot System
• Gather feedback on Pilot and update deployment
confi guration
• Deploy applicable Development, Test, and Staging environments
• Production Go/No-Go Decision
SAMPlE DEPlOYMENT PlAN (2)
checklist-front.indd 5 10/23/2007 5:09:39 PM
SAMPlE DEPlOYMENT PlAN (3)
DEPLOYMENT, IMPLEMENTATION, & CONFIGURATION MANAGEMENT
(continued)
• Deploy Production System
• Install Hardware
• Install Software
• Confi gure Software
• Confi gure server, software, and network dependencies
• Confi gure Search
• Confi gure Document Management
• Confi gure Personal Sites
• Review single sign-on service requirements, consider
Kerberos
• Confi gure Microsoft Offi ce SharePoint Server 2007 for
extranet use as desired
• Implement solutions and applicable third party
solutions, if any
• Deploy updates to Client Machines as needed
• Test and Evaluate System
POST-IMPLEMENTATION OPERATIONS, OPTIMIZATION, AND
BUSINESS REVIEW
• Deployment Complete
• Maintain IT Governance through Service/Business Reviews
• Maintain regular Reporting in Support Operations and Change
Management Reviews
For a complete sample SharePoint Deployment Plan, go to:
http://go.microsoft.com/fwlink/?LinkId=102043&clcid=0x409
checklist-front.indd 6 10/23/2007 5:09:41 PM
INFORMATION ARCHITECTURE
Ensure understanding of what information architecture is and how it
ts in with the Intranet strategy
Ensure stakeholders understand why information architecture is
critical
Consider hiring an information architecture professional
Build wireframes for 4-5 most popular pages (for example, a Home
page, a Policies and Procedures page, a Department page, and a
Search Results page)
Design simple sketches for each wireframe (links, content and full
functionality to be added later)
Create a sitemap to plan the overall structure
Create sitemap subsections for popular groups or departments,
then build out lower-level sections, such as Project sites
Build content types for structured departments, regions, or business
site collections
checklist-front.indd 7 10/23/2007 5:09:41 PM
PROjECT & OPERATIONAl MANAgEMENT
Establish a communications plan (include):
Who will do communications plan?
When the communications will occur?
What the communications will contain?
What format the communications will be in?
Create contacts list and include links for those involved across the
deployment, include stakeholders and global operations contacts
Dene a deployment process for in-house and third-party software
Dene how changes will be tracked, catalogued, and approved
Decide where older versions of congurations, code, and compiled
components will be stored
Decide if you will be allocating costs back to business or not:
WILL NOT: consider where the costs will be centered (compare
with e-mail)
WILL: Consider what metrics you’ll use for the charge back (# of
sites, amount of storage, amount of activity, etc.)
Establish a SharePoint Governance board to review adoption and
controls
Solicit executive champions to create management attention to the
value of the initiative
Encourage business evangelists to share power of SharePoint with
other business leaders
change management process
deployment process
communication
cost allocation
sponsorship
checklist-front.indd 8 10/23/2007 5:09:41 PM
PROjECT & OPERATIONAl MANAgEMENT
Dene clear roles and responsibilities for the initiation of the
SharePoint technologies platforms
Dene clear roles and responsibilities for the initiation of the
SharePoint operation
Dene strategic teams to address strategy issues
Establish cross-functional problem resolution to address complex
issues which arise
Establish a Change Control Board and Reviews – Establish rst who
will be on the board, then what need to be reviewed, and what is
considered for exceptions with a recurring change review.
Create a service level agreement around the length of time and
approvals necessary to create a site
Establish service level agreements for problem resolution through
the help desk
Negotiate performance service level agreements for the rst load
of a site, subsequent loads of a site, and performance at remote
locations
Establish a maintenance window – When and how long is an
acceptable window for downtime for patching, and pushing
changes out to the environment which require worker process
resets.
Establish a Recovery Time Objective - How long can SharePoint be
down for unplanned downtime.
Establish a Recovery Point Objective - How long can the business
tolerate a recovery from a software, hardware, and datacenter
disaster. This will help you in your Disaster Recovery plan. Be sure
to test your plan on a recurring basis.
roles and terms
service level agreements
checklist-front.indd 9 10/23/2007 5:09:42 PM
DEVElOPMENT & CONFIgURATION
Dene what customization tools will be allowed
Communicate what actions will be allowed and not allowed in the
tools (i.e. unghosting)
Establish guidelines for the development of site denitions and
mechanisms for coordinating ID usage
Communicate policies for site template deployment, such as the
requirements for a globally installed template
Determine if a central repository will be required for all code
installed on the platform
Establish standards for building components either on a centralized
server or as guidelines for building software
Communicate expectations as to reference documentation
(compiler generated) and warnings (whether they are allowed)
Describe the responsibilities of business unit for ongoing code
support
Consider guidelines for which assemblies may be installed to the
Global Assembly Cache (GAC) and which may not
Establish rules about the use of the AllowPartiallyTrustedCallers
Establish Life Cycle Development best practice for packaging and
rolling out change including support and test reviews. Require
Features, Solutions, and installation packaging including rollout and
roll back scenarios.
Establish add-ons and third party solutions change management
approval process and support SLAs.
site denitions and templates
customization tools
source code and build control
on-going source code support
development standards
checklist-front.indd 10 10/23/2007 5:09:42 PM
DEVElOPMENT & CONFIgURATION
Establish templates for what the SharePoint sites will look like
Determine which types of sites may be modied and which may not
Dene which parts of the template may be changed by site owners,
and which may not
Create and manage a master page gallery and create solution
deployments packages to rollout if necessary
Ensure that your site’s visual designer includes some sort of
branding in all content creation
Require use of templates on higher level pages to enforce brand
consistency
Remember to allow room for sub-branding of individual teams or
project brands
branding
checklist-front.indd 11 10/23/2007 5:09:42 PM
INFRASTRUCTURE
Consider rules for outbound connections from the web servers for
use by the XML and RSS Viewer web part
Communicate rewall and security restrictions including any web
part restrictions such as ActiveX controls or external RSS
Decide upon and communicate the backup, clustering, load
balancing and failover strategy and related service level agreements
Dene the environments which will be used to develop and test
solutions in SharePoint
Describe the actions which are expected and those which are
prohibited in each environment
Communicate policies for site template deployment such as the
requirements for a globally installed template
environments
recovery, load balancing and failover
rewalls
checklist-front.indd 12 10/23/2007 5:09:42 PM
TESTINg & PROVISIONINg
Prior to launch, require content owners or editors to test their own
content
Offer a convenient mechanism for site owners to provide testing
feedback
Create thorough test plans and let site owners know specically
what you want them to test
Determine an approval process for information policies such as
expiration, compliance and auditing
Establish and document user policies and rights policies including
securing restricted areas
Publish guidelines outlining appropriate application and content
types
Consider forbidding condential data on your SharePoint site or
limiting it to specic site collections or web applications which are
more tightly controlled, audited, and managed
Clearly dene remote access policies to ensure security
provisioning
testing
checklist-front.indd 13 10/23/2007 5:09:42 PM
OPERATIONAl CONCERNS
Establish monitoring at the server and web application level
Dene responses to each type of failure that may occur; use
Microsoft Operations Manager Packs for applicable areas in the
deployment such as IIS, SQL, WSS 3.0, and SharePoint Server 2007
Dene scheduled downtime periods if needed
Communicate the procedure to report unscheduled downtime or
specic performance issues (consider using another medium for
outage notication)
Dene response procedures to unscheduled downtime
Plan for single le recovery (perhaps using version control and the
recycle bin)
Plan for single or multiple site recovery
Plan for server recovery
Plan for data center recovery
Codify corporate records management requirements into SharePoint
Dene rules for archive of sites including warnings and approvals
Establish default storage quota templates by web application
Establish process for requesting a larger quota, including maximum
quotas
Dene required auditing reports and establish storage usage reports,
including how the data will be gathered and frequency
Develop activity based reporting for administrators and business
users
disaster recovery
monitoring, uptime and downtime
data and document recovery
quotas and reporting
checklist-front.indd 14 10/23/2007 5:09:42 PM
EDUCATION & TRAININg
Include realistic training costs as part of your earliest estimates
Allocate budget for IT staff, Development staff, and business users.
Consider train the trainer and onsite training to reduce costs
Acquire end user training and resources
Acquire help desk training and resources
Acquire administrator training and resources
Develop administrator policy guides which describe organization
specic policies
Acquire developer training and resources
Develop developer policy guides which describe organization specic
development policies
Provide separate training for site managers, application designers,
information workers, and end users
Create online forums where users can support each other and ask
questions
Create opportunities for face-to-face learning in unstructured or
semi-structured environments, such as lunch and learns or after
hours discussions
Plan for renewal training which gathers the learning from multiple
groups and exposes it to other groups
Perform periodic audits of the platform to discover what features are
not being utilized and which features are not being utilized correctly
community development
training budget
renewal training
initial training
checklist-front.indd 15 10/23/2007 5:09:42 PM
NAVIgATION & TAXONOMY
Give one group control over the taxonomy
Consider hiring or utilizing a professional taxonomist or in house
taxonomist who has been trained or has experience with SharePoint
technology
Use the taxonomy for consistent labeling of the site
Build one set of taxonomy labels prior to nalizing your wireframes
Update taxonomy to provide useful search metadata
Dene the structure of the site directories including the major
groupings and associations
Develop a linking strategy between different types of sites such as
enterprise, divisional, departmental, team, etc.
Dene core content types in the organization and include in site
templates or site denitions
Dene key elds to link documents and operational systems
content types
site directories
taxonomy
checklist-front.indd 16 10/23/2007 5:09:43 PM
ENTERPRISE SEARCH
Assign workows for content creation so only the best information is
available for search indexing
Integrate your taxonomy with search planning
Use hit highlighting, best bets, and people search
Incorporate alternative content forms such as blogs and Wikis into
your search results
Utilize BDC functionality in SharePoint to enable search on customer
relationship management or partners, products and more
Establish content sources to the le based repositories in the
organization
Use the Business Data Catalog to allow searching of business data
Dene who will be responsible for core relevancy settings
Implement organizational enhancements of the noise words le,
thesaurus le, and keyword best bests
search
search locations
search relevancy
checklist-front.indd 17 10/23/2007 5:09:43 PM
SHAREPOINT RESOURCES
TECHNET SHAREPOINT TECH CENTERS
SharePoint Server:
http://technet.microsoft.com/moss
Windows SharePoint Services:
http://technet.microsoft.com/sharepoint
MSDN SHAREPOINT DEVELOPER PORTALS
SharePoint Server:
http://msdn.microsoft.com/moss
Windows SharePoint Services:
http://msdn.microsoft.com/sharepoint
SHAREPOINT TEAM BLOG
http://blogs.msdn.com/sharepoint
SHAREPOINT DISCUSSION FORUMS Q&A
http://www.mssharepointforums.com
checklist-front.indd 18 10/23/2007 5:09:45 PM
SHAREPOINT DEPLOYMENT GUIDE AND CHECKLISTS
AKNOWLEDGEMENTS
THIS DOCUMENT IS FOR INFORMATIONAL PURPOSES ONLY. MICROSOFT MAKES NO
WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT.
©2007 MICROSOFT CORPORATION. ALL RIGHTS RESERVED. MICROSOFT, THE OFFICE LOGO,
AND MICROSOFT OFFICE SHAREPOINT SERVER 2007 ARE EITHER REGISTERED TRADEMARKS
OR TRADEMARKS OF MICROSOFT CORPORATION IN THE UNITED STATES AND/OR OTHER
COUNTIRES.
MICROSOFT CORPORATION. ONE MICROSOFT WAY. REDMOND, WA 98052-6399. USA.
CONTENT CREATION
AND PRODUCTION
JOEL OLESON, MARK WAGNER, ARPAN SHAH,
JEFF TEPER, MIKE WATSON (MICROSOFT CORPORATION)
SCOTT CASE, ROBERT BOGUE (SHAREPOINT MVP),
SHANE YOUNG (SHAREPOINT MVP), VARIOUS
CONSULTANTS AND BUSINESS RESOURCES FROM
INTERKNOWLOGY AND ASCENTIUM
DESIGN PROWESS CONSULTING, LLC., SEATTLE, WA
PART NO. 098-108909
checklist-back.indd 1 10/23/2007 5:11:38 PM
ENTERPRISE SEARCH
search relevancy
The Business Data Catalog provides the bdcMetadata.XSD le, an XML
Schema Denition File (XSD) that denes the XML element mapping
structure necessary for creating an Application Denition le. When
authoring metadata using Microsoft Visual Studio 2005, valuable
IntelliSense support can be gained by copying XML denition to a
working folder and setting the schemaLocation attribute of the root
element to point to this schema. The BdcMetadata.XSD le can be located
in the “\Bin” folder of the Ofce SharePoint Server 2007 installation
directory, normally located at “<root>\Program Files\Microsoft Ofce
Server\12.0\Bin\”.
When developing BDC Application denitions, the easiest approach to
creating the denition is to include all elds in the table, making them
available for later use by anyone. Typically, an organization will be very
selective as to which elds are available to end users. Depending on the
architecture of your application, some elds may be sensitive or even
encrypted. This can produce extended discussions on which elds are
useful and appropriate for users throughout the organization. It may be
that an organization decides to create multiple Application Denitions
to the same data structure, one perhaps complete with all elds and one
restrictive with limited eld access, then assigning specic permissions only
allowing company access to the more restrictive of the denitions.
Web Parts are the easiest way to surface data from new Application
Denitions. When clicking “Add a Web Part” on any SharePoint page,
select “Business Data List” and add it to the page. When rst added, the
Web Part properties must be set to use an available BDC Entity as its
source. (For readability, select “Edit View” from the toolbar).
the business data catalog
multiple bdc application denitions
using web parts to add application denitions
checklist-back.indd 2 10/23/2007 5:11:39 PM
NAVIGATION & TAXONOMY
A taxonomy is a structured way of ordering words, labels, tags, etc.
for a Web site. It’s similar to a vocabulary list with a set of guidelines
for denitions and usage. A taxonomy helps to dene and control
the way a Web site is organized, what things are named, and how
people nd information. In short, a taxonomy makes it easier to
organize and nd things on a Web site.
TAXONOMIC SECTION CHARACTERISTICS OWNERS
Central/Corporate
Portal
• Permanent
• Controlled; tightly governed
• Push information to users
• Dashboards, Business
Intelligence, BPM
• Applications, Content
• Portal
administrators
• Corporate
stakeholders
Division Portals • Permanent
• Controlled; tightly governed
• Push information to users
• All public sites - content is
divisional information
• Dashboards, Business
Intelligence, BPM
• Applications, Content
• Portal
administrators
• Divisional
business owners
Department, Group
& Team Sites
• Permanent and Temporary
• Sharing information (push/pull)
• Collaboration
• Ad hoc, lax control
• Divisional
business owners
• Departmental
business owners
Project Team Sites
and Workspaces
• Short lived, timed expiration
• Collaboration
• Ad hoc, lax control
• Departmental
business owners
My Sites • Permanent
• Personal info
• Pull information
• Ad hoc, lax control
• Portal
administrators
• Employees
taxonomy governance model
checklist-back.indd 3 10/23/2007 5:11:39 PM
EDUCATION & TRAINING
System Administrators:
This role is responsible for Server and database management and will
allocate physical infrastructure, install SharePoint, provision and congure
web applications, and provide for top level security administration.
Training should include deployment practices, SharePoint Central
Administration, monitoring, maintenance, backup/restore, disaster
recovery, and management of Shared Service Providers.
Developers:
This role needs education on the structure to be followed in the
organization for developing add-ins and solutions based on SharePoint
technologies. This should include the deployment process, development
environments, development life cycle management, coding standards,
and policies such as security levels and whether code can be deployed in
the GAC.
Help Desk Personnel:
This role is the rst in line to the end users. Much of the training and
education for the help desk should be focused around problem resolution
and how to locate the right resources when needed.
Information Workers:
This role congures and extends site and list level feature sets. This
includes branding, advanced Web Part features, workows, and other
integration points. Training should include SharePoint Designer, Shared
Service Provider interface for Search or other Service Management, Site
Settings, InfoPath, and standard SharePoint site administrator interfaces.
End Users:
This role will account for the bulk of SharePoint users and skills will vary
greatly. Core daily use will include basic navigation, search, and document
management. Focus should be on understanding lists, user interfaces,
navigation, workows, upload, ofine, and interaction with client
applications.
most common roles and suggested training
checklist-back.indd 4 10/23/2007 5:11:39 PM
OPERATIONAL CONCERNS
It’s important to monitor at the level of detail that will let you know with
condence that if the site is down that you will be notied there is a
problem. You can do this by pinging the server, checking the status of
services, testing health-check pages, etc. Failure of the system to respond
in the expected way may be a reason to alert administrators or take
automated actions to take the server out of the load balancer. Dening
what the monitoring policies are, including who will be notied when
there is a problem with the server, or with an individual site will eliminate
confusion as to who owns the resolution of server problems – including
problems with specic sites.
The fundamental building block of disaster recovery plans are backups.
Backups of the data, failover hardware, and redundant connectivity. The
way that backups are performed is essential to the SharePoint governance
process because it establishes expectations on what is recoverable or not.
Dening the process for requesting recovery and the timeline for that
recovery further establishes the kind of expectations from SharePoint
that improve adoption. Be sure to consider a variety of disasters: natural
(ood, re, tornado, earthquake), server (ofine, dead), user accidents (le
deletion, saving issues, crashes), and site (failure, corruption, error).
Centralized SharePoint platforms must be concerned about total storage.
SharePoint can rapidly become the new le storage platform within an
organization – and as a result consume massive amounts of storage very
quickly. One of the ways to combat this problem is to establish quotas for
sites as they are created. Each site is given a small amount of storage and
they’re allowed to request more as they need it. The governance process
should include the amount of space initially allocated by type of site
being provisioned as well as the process for requesting more space.
monitoring
disaster recovery and backup
storage and quotas
checklist-back.indd 5 10/23/2007 5:11:39 PM
TESTING & PROVISIONING
Prior to launching, require site owners to test their own content. Set up
schedules for them to review content every other day during the testing
cycle.
To make it as easy as possible to hear back from these testers, provide
an online form or similarly convenient way for site owners to provide
feedback during testing. You need to get feedback fast to make changes,
so don’t get bogged down in massive spreadsheets.
It’s best to create test plans that test all necessary functionality, such
as links to other programs. Provide site owners with a specic checklist
of exactly what functionality you want them to check. If you make the
assumption they’ll just know what to do, you may be disappointed with
the results.
Building a strong user acceptance testing plan up front will help business
stakeholders see for themselves that the project objectives have been
met, before the intranet is widely available.
The fundamental building block of disaster recovery plans are backups.
Backups of the data, backup hardware, and backup interconnection
gear. The way that backups are performed is essential to the SharePoint
governance process because it establishes expectations on what is
recoverable or not.
pre-launch testing
testing plan
test environments
checklist-back.indd 6 10/23/2007 5:11:39 PM
INFRASTRUCTURE
It is a best practice for rewalls to not allow servers to access the web
directly. Including content from a third party site through a content editor
web part or through the RSS reader web part creates exposure for cross
site scripting attacks. Controlling what sites can be linked to from these
tools is a security and operational concern.
It is typical to prevent outbound web connections from the server on port
80 or 443. This is designed to prevent malicious sites from being run on
the server and to make it harder for any potential infection to report back
on the infection’s success.
Load balancers keep alive pages that they expect to return a standard
value to indicate that the server is operational. These pages often are
called frequently and have a very low tolerance for a response time.
Because of this the load balancers will need to be congured to access a
health page. Determining a policy for what goes on this health page and
what criteria the load balancer should use to indicate that a server has
failed can be essential for high availability applications. Developers must
know if they are expected to handle situations where a single session is
transferred between servers.
Dening the environments for development, testing, staging or user
acceptance and deploying helps business uses and developers know
what resources they have available to test changes without impacting
production.
rewall best practice
load balancing
dening environments
checklist-back.indd 7 10/23/2007 5:11:40 PM
An example of a basic wireframe mirroring the out-of-the-box
functionality and layout of a standard Master Page is shown below. This
breaks down the functionality to its most basic component on a page.
Once the wireframe has been drafted and its end user functionality has
been validated, designers can apply branding and visual treatments to
the interface. Visual compositions may take several rounds to ensure
that visual design, functional design and stakeholder acceptance reach
agreement. In fact, this phase should be carefully managed.
DEVELOPMENT & CONFIGURATION
master page wireframe
Content Area
WebPart Zone
Title
Search
User Menu
Home Link
Site Title & Logo
Global Navigation
Current Site Navigation
Recycle Bin
after drafting and validating the wireframe
checklist-back.indd 8 10/23/2007 5:11:40 PM
DEVELOPMENT & CONFIGURATION
Microsoft Ofce SharePoint Server 2007 provides a template-like
approach to branding where most of the user interface may be
completely redesigned to a detailed design requirement. ASP.NET 2.0
Master Pages allow for a globally applied template background to all of
SharePoint’s user and administration screens. By modifying or creating
your own custom Master Page via Microsoft Ofce SharePoint Designer
2007, unique visual presence and functionality can be achieved.
In SharePoint, site denitions are le system-based resources from which
all sites are built. Site templates are a set of changes to be applied to a site
automatically after the site is created from a site denition. Understanding
and communicating the difference between site denitions and site
templates is important because site denitions require unique identiers
and therefore, coordination. Site templates, on the other hand, require the
underlying site denition that was used to create them and as such, their
creation should occur only from approved site denitions. Upgrade and
consistency are major factors in the decisions whether or not to use site
templates or site denitions. Both will require some effort to upgrade, but
site denitions will require more effort.
Environments with as many different components as SharePoint need a
level of consistency when software is developed and built. Simple things
like patches on a computer used to build code can have dramatic impacts
on the overall solution. Dedicating a computer to the purpose of building
all of the code to be deployed into production is a good risk management
approach. There is the potential that for many different internal and
external groups developing code for the SharePoint platform, having one
repository for all of code may not be the rst choice. Each development
group may maintain their own source code repository. One consideration
for governance is if your size of installation warrants a policy that requires
all code be built on a centralized build computer from a centralized
source code repository.
master pages
site denitions and site templates
building code
checklist-back.indd 9 10/23/2007 5:11:40 PM
PROJECT & OPERATIONAL MANAGEMENT
Dening roles within the governance team and within SharePoint
deployment at large is a seemingly uncomplicated task that often
becomes difcult as staff rotates. Consider dening roles around: project
management, service owner, operational management, and development.
Project Management:
These roles include actions which must occur to manage the project
through to completion. Time and cost management of the platform
project, communication of objectives, ensuring the production of
deliverables, guiding the timelines, and management of expectations are
all critical actions that should happen from a project management role(s).
Service Owner:
These roles are for managing the ongoing life of a centralized governance
and platform. Service Manager or owner roles are the advisory or steering
committee roles which will guide the SharePoint governance over the
long term. Explaining what actions are expected out of these roles as well
as the frequency of commitment can be helpful.
Operational Management:
These roles are responsible for the day-to-day care and feeding of
the system including backups and restores, monitoring, and capacity
management. These do not have to be dedicated roles but are instead
roles which already exist within your organization. They should be dened
as a part of the SharePoint governance in order to make it clear what
kinds of operational management support is expected.
Development:
These roles may seem odd for a centralized platform. The platform itself
may largely be out-of-the-box functionality of SharePoint. However,
integrating SharePoint into your environments, handing secure sign on,
creating site denitions, and many other tasks may best be centralized so
no one user must bear the burden and consistency exists throughout the
solution.
dening roles
checklist-back.indd 10 10/23/2007 5:11:40 PM
PROJECT & OPERATIONAL MANAGEMENT
Enterprise:
A plan for enterprise sites has the highest level of governance associated
with it. Enterprise sites tend to be focused on communication – on
the dissemination of information and not so much on collaboration or
working together. Because it will be accessed by the entire organization,
it’s essential that it match the relative appearance of the other sites
and that it be available most of the time. Out-of-band patches and
upgrades to core functionality implemented through code will need
to be minimized. Taxonomy and the need for a consistent approach to
organization of information is necessary as well.
Departmental:
Departmental sites still have a large number of users even if the entire
enterprise isn’t dependant upon them. Having specic governance
around departmental sites allows you to relax some standards for
enterprise-type sites and create solutions which more directly t the
collaborative needs of the department. The departmental site may still
have governance on branding but may allow more out-of-band updates
to core code leveraged by the departmental site. Where decision making
is more centralized about the types of updates that can be made to
an enterprise facing site because of their broad use, decisions about
implementation schedules for departmental sites can, and should, rest
with the department.
Ad-Hoc:
Perhaps the greatest volume of SharePoint sites are ad-hoc sites created
to support meetings, committees, or other sub-groups which have less
formal structure and fewer people than a departmental solution. Ad-hoc
sites need less governance, except in the areas of quota and retention.
While enterprise and departmental sites have a long life, ad-hoc sites
may live only a few days, such as sites supporting the development of an
RFP response, or a few weeks, like a site for a company picnic planning
committee. Because of the large volume of requests and the short
duration of the need developing a policy around site retention (and
therefore document retention) is critical.
common site classication types
checklist-back.indd 11 10/23/2007 5:11:40 PM
INFORMATION ARCHITECTURE
More often than not, companies fail to plan for adequate testing of the
site prior to launch, resulting in everything from broken links to a site
that doesn’t meet the original business stakeholders’ goals. Organizations
typically fall short in adequately training employees on how to use or
create content for the intranet, once again severely reducing its ongoing
value.
So, what specically can you do to eliminate chaos and build a better
intranet from the start? Use Microsoft Ofce SharePoint Server to create a
managed single environment, and build in plans for governance up front.
A Web site’s information architecture determines how the information in
that site — its Web pages, documents, lists, and data — is organized and
presented to the site’s users. Information architecture is often recorded as
a hierarchical list of site content, search keywords, data types, and other
concepts.
Analyzing the information to be presented in an Internet or intranet Web
site is an important early step in the site planning process, and this step
provides the basis for planning:
• How the site will be structured and divided into a set of site collections
and sites.
• How data will be presented in the site.
• How site users will navigate through the site.
• How information will be targeted at specic audiences.
• How search will be congured and optimized.
Although this section provides some guidance on how to analyze the
information requirements of your Internet or intranet site, you will want
to include an information architect or analyst on your site’s planning and
design team to ensure that your Web site plans fully take into account the
information architecture needs of your organization.
about information architecture
checklist-back.indd 12 10/23/2007 5:11:40 PM
SHAREPOINT DEPLOYMENTS INVOLVE IT, INFO WORKERS, DEV TEAMS AND THE BUSINESS
Business
Stakeholder
Server
Administrator
Information
Worker
Stakeholder
Requirements
Discovery
Requirements
Discovery
Design
Sign-Off
User
Acceptance
Acceptance
User Training
Administrator
Enterprise
Discovery
Enterprise
Discovery
Enterprise
Planning
Design
Enterprise
Planning
Server
Build-Out/
Installation
Build-Out/
Data
Migration
Integration
Testing
Con guration
Design
Custom
Development
Custom
Development
Site
Con guration
Con guration
Integration
Testing
checklist-back.indd 13 10/23/2007 5:11:41 PM
STEPS TO A SUCCESSFUL MANAGED DEPLOYMENT
1. Consistency of platform, browsers, collaboration and enterprise search
strategy.
2. Manage as centrally as possible with a tight team with a means to
communicate to the CXOs that have a vested interest.
3. Have a killer backup strategy that meets the needs of your business and
make sure it works before day one.
4. End-user training and education in addition to good content and
search is the key to end user adoption.
5. Have a Governance and Information Management Plan. Branding
consistency with a corporate style guide and consistent taxonomy.
Make approved master pages available in site galleries for consistency
which will inform users they are on the corporate Intranet.
6. Enforce work ows and approval on document centers and pages where
of cial documentation comes together. Leverage version history and
version control to maintain a history and master document that all can
refer to.
7. Life cycle managed site collections, and document libraries with
information management policies such as content types with auditing
and expiration.
8. Properly secure corporate assets. Sites with (PII) personally identi able
information should be appropriately  agged and secured and audited.
9. A corporate browse and search strategy for the enterprise will ensure
you are making the most out of your intranet assets as well as
encourage culture change, best practices and adoption.
10. Platform Usage Policies and development and test environments ensure
only the code you want to introduce follows corporate guidelines and
will ensure the environment is supportable and able to maintain SLAs
(Service Level Agreements).
checklist-back.indd 14 10/23/2007 5:11:43 PM
SHAREPOINT GOVERNANCE PLAN:
INTRANET MODEL.
Microsoft Of ce SharePoint Products and technologies are powerful
and effective tools that increase collaboration and communication in
a shared environment. SharePoint technologies offer a  exible and
ef cient way for users to create their own workspace solutions for
collaborative projects and groups.
However, as with other collaboration environments without proper
governance, a SharePoint deployment can become unmanageable,
a disorganized collection of sites, users and links, through the same
pathways that provide such  exibility and power when properly
deployed.
In a balanced and well-de ned SharePoint governance plan,
consistent rules and guidelines are instituted that give users just
enough  exibility and control to produce customized, manageable
solutions, but also provides enough oversight so that the solutions
retain manageability.
checklist-back.indd 15 10/23/2007 5:11:47 PM
COMMON SHAREPOINT PHYSICAL TOPOLOGIES
WSS 3.0 OR
SHAREPOINT
SERVER
STANDALONE
WSS 3.0 HIGH
AVAILABILITY
SHAREPOINT
SERVER HIGH
AVAILABILITY
User Requests
Web Server
Index Server
Database
User Requests
User Requests
Each server includes:
• Web Server
• Application Roles
Clustered or Mirrored SQL Server
Clustered or Mirrored SQL Server
Index Server
Web Servers
checklist-back.indd 16 10/23/2007 5:11:49 PM
SHAREPOINT CONTAINMENT HIERARCHY
checklist-back.indd 17 10/23/2007 5:11:51 PM
SHAREPOINT DEPLOYMENT TEAM ROLES
SharePoint Business Analyst or
Services/Project Manager
SharePoint Creative
Designer
SharePoint Trainer
SharePoint Infrastructure
Specialist(s)
SharePoint
Developer(s)
SharePoint Architect
SharePoint Site
Administrator(s)
Business
Intelligence
Collaboration
Business
Forms
Portal
Content
Management
Search
Platform
Services
checklist-back.indd 18 10/23/2007 5:11:55 PM