so you’re building an intranet

55
So You’re Building an Intranet Becky Bertram Independent SharePoint Consultant, SharePoint Server MVP www.beckybertram.com With contributions from Mike Henthorn Covenant Technology Partners, St. Louis http://mhenthorn.blogspot.com/

Upload: beckybertram

Post on 28-Oct-2014

137 views

Category:

Software


1 download

DESCRIPTION

Presentation from 2010 outlining steps that an IT manager needs to take when planning an initial SharePoint 2010 intranet site.

TRANSCRIPT

Page 1: So you’re building an intranet

So You’re Building an Intranet

Becky BertramIndependent SharePoint Consultant, SharePoint Server MVP

www.beckybertram.com

With contributions from Mike HenthornCovenant Technology Partners, St. Louis

http://mhenthorn.blogspot.com/

Page 2: So you’re building an intranet

Project Planning

Page 3: So you’re building an intranet

Evaluating Scope and Granularity

Page 4: So you’re building an intranet

Stakeholder = person footing the bill Important to prove business value and ROI This person is sometimes more concerned with

dollars and cents than usability. Usability must translate into cost savings.

End-user = person using the system once it’s build This person doesn’t care how much the system cost.

They care if it helps them do their job better. May not have an eye on the big picture. May wish

they could post pictures of their pets on their My Site more than whether the site saves the company money.

Stakeholders vs. End Users

Page 5: So you’re building an intranet

Important to get input from both stakeholders and end-users (but not necessarily at the same time).

Stakeholders have final say in what gets built, but they must understand needs of their users.

Find representatives throughout your organization who know their business processes for their particular area/department.

Find tech-savvy “champions” who are excited about technology and are not afraid of change.

Steering Committee

Page 6: So you’re building an intranet

Users either love or hate what they currently have, but it will serve as their frame of reference.

It’s important to get people to dream, whether that means giving them hope that something better is out there, or opening their eyes that there might be a better way of doing things than they have done things for the last decade.

A key to getting them to dream is to show what’s possible. Demoing gives people more understanding than talking about SharePoint’s features.

The Curse of the Past

Page 7: So you’re building an intranet

When working with stakeholders, they might continually whine or lament that the new system lacks what either their current system does, or some system they worked with at another job.

Set the expectation that SharePoint is not WebSphere, Documentum, Fill-in-the-blank…

Sell SharePoint, but don’t oversell it. It won’t do their laundry or buy their groceries. It’s a tool, and it can be customized for their needs.

The Curse of the Past, Continued

Page 8: So you’re building an intranet

Import for everyone to feel heard. Take a note of everything they wish to see.

Begin a process of group prioritization. If this is done as a group, everyone gets a

vote. If the loudest person insists on a priority, but it becomes apparent it’s only important to them when it comes to the voting process because it only gets their one vote, it’s hard for them not to understand if it doesn’t get implemented.

Primarily stakeholder(s) get a greater vote than everyone else. Dems da berries.

Requirements Gathering

Page 9: So you’re building an intranet

Create a matrix of: costly, important, cheaper, unimportant. Prioritize the requirements along this continuum.

Prioritization

Costly and important Costly and less important

Less costly but more important

Less costly and less important

Page 10: So you’re building an intranet

A house needs a foundation before you can hang the curtains.

When calculating “important” things, think about things that cannot be easily changed once you start your implementation. How users authenticate Number of site collections Retention policies Base content types Server location (hosted or on-premises)

First Things First

Page 11: So you’re building an intranet

Easier to start with limited functionality and add it later. Too much functionality too early: Increases the chances that users are overwhelmed

and quickly disregard the whole system Increases the chances that users don’t know how

to use the system properly and make mistakes, causing frustration and limited usage of system.

Because of increased complexity, causes increased maintenance for site and farm administrators, who are new to this system as well.

Better to start with limited functionality with a strategy for expanding functionality later.

Starting Small

Page 12: So you’re building an intranet

People hate change, by and large To get people excited about using the new system,

work to get their “buy-in” earlier than later. Do it while you’re building the system. Don’t present them with a shiny new system and than be disappointed when they don’t care about your pet project.

Ways to get buy-in: Periodic updates on project’s status. Perhaps this is in

an e-mail, a newsletter, etc. Prepare people for this new change that will happen.

Periodic demonstrations of new functionality Solicit feedback during the process

Encouraging Adoption

Page 13: So you’re building an intranet

…they will not necessarily come.

A SharePoint site must present users with a better way of doing their job than they do it now. No Outlook = no e-mails at work.No SharePoint = business as usual (i.e. e-mailing documents, e-mail discussion threads, etc.)

People will NOT voluntarily add meaningful content to the site if they are not assigned it as a part of their meaningful job tasks. Make sure people understand this is a priority and not just “one more thing” they have to do. (Wikis, blogs, discussion boards seem like a great idea until no one uses them. )

If You Build It…

Page 14: So you’re building an intranet

Planning your Site

Page 15: So you’re building an intranet

This has an effect on a number of things: Technical:

Server load Maintenance

Logistical: How many people need training? How many people will need to be administering

the content on the site? How will you find your “champions”?

Number of Users

Page 16: So you’re building an intranet

How many logical sites will be built? The smaller the granularity, the greater the number. You might need one public facing site You might need one intranet portal homepage You might need 5 departmental sites You might need 100 team sites You might need 300 My Sites

Scope and Frequency

Page 17: So you’re building an intranet

Object model, navigation, browser tools, only work within one site collection. Better user experience when one site collection is used.

Monster big site collection = monster big database = bad disaster recovery scenario

Reasons for splitting site into site collections: Smaller DB sizes, i.e. faster backup and restore

scenario per DB. Quotas Expiration and deletion

Number of Site Collections

Page 18: So you’re building an intranet

My Sites (Quota, permissions, OOTB) Project or team sites (Quota, expiration) Ad hoc sites (Quota, expiration) Document-heavy sites (Database size)

When do multiple site collections make sense?

Page 19: So you’re building an intranet

Will your site need to support more than one language? Will the infrastructure team need to install

language packs? Will you be using site variations? How will the translation process work?

Multi-lingual Sites

Page 20: So you’re building an intranet

Ad Hoc: Nearly anyone can create a site, create lists, add or remove content, etc.

Controlled content creation: SharePoint Administrators, Site Administrators put in place to limit who gets to create or modify content.

Publishing sites: Greatest level of control; usually only Content Owners are given permission to create content; page templates are pre-defined.

Spectrum of Control

Ad Hoc Publishing

Page 21: So you’re building an intranet

Advantage of enabling Publishing in your site: branded look and feel, more pleasant Web experience.

Disadvantage of Publishing: meant for public facing Web sites, primarily. Can be inconsistent user experience if Publishing pages used for news stories while list views are used for lists, etc.

Blended approaches: Publishing and collaboration are layered in the same

site Publishing in one site collection, collaboration split

off in another area of the site

Publishing or No Publishing, that is the question

Page 22: So you’re building an intranet

Benefit of SharePoint is that it allows for distributed use and maintenance.

For it to be effective, responsibility must be delegated.

How much centralized control do you want to cede in order to encourage distributed ownership? Depends on job responsibility or initiatives of

end users Maybe means making a distinction between

“official” and “unofficial” content. (Workflows, or publishing vs. non-publishing sites.)

Delegation

Page 23: So you’re building an intranet

Think task over org chart People come to a page or a site because they

are trying to accomplish something Logical structure is also tied to security Key to effective content management is

creating multiple ways to retrieve the same data

Metadata, metadata, metadata: Sorting, grouping, filtering on lists Relevant search terms for data retrieval Content queries

Site Organization

Page 24: So you’re building an intranet

Columns: At the global level, emphasize search-ability and retrieve-ability. At the list level, emphasize sorting, filtering, grouping, etc.

Content Types: Can be used for workflows and policies, as well as a collection of columns or document templates.

Global vs. local Fewer the better Take advantage of content type inheritance

Base content type at the top Inherited content type at the list level

Content Types and Metadata

Page 25: So you’re building an intranet

Custom Search Scopes and/or Search Tabs Customized Advanced Search page Customized Results Customized Refinement Panel Canned Searches

Search

Page 26: So you’re building an intranet

Approval workflows Sequential or parallel Who’s in the workflow groups?

Are you using a Records Center? Are you archiving content? Do you need to set up routing rules?

Are you implementing expiration policies on your content?

Workflows

Page 27: So you’re building an intranet

Social media components can be implemented independently of one another. Use Personal Features

Contains Memberships, such as SharePoint sites and distribution lists; Colleagues, such as the My Colleagues list and colleagues recommendations; My Links; My Personalization links, such as personalization site pinning; and User profile properties.

Create Personal Site Creates a My Site Web site, which includes a personal, private My Home page and a public My Profile page.

Use Social Features Includes social tags, Note Board, and ratings.

(From http://technet.microsoft.com/en-us/library/ee721063.aspx)

Social Media

Page 28: So you’re building an intranet

Each user’s My Site is a new site collection. Possible to make changes to a site collection before it’s created. Doubles the effort or more to make changes to existing site collections after the fact, as well as provide for changes in new sites to be created in the future.

How does management feel about My Sites? Do they see it as “wasting time”?

How will you monitor the content that people publish? Are there policies in place if someone misuses their My Site?

Storage space estimate and quotas should be in place before enabling.

My Sites

Page 29: So you’re building an intranet

How will you get content from your existing site (if you have one) into your new site?

What’s the process of scrubbing data before bringing it over?

Migration options: Manual Programmatic Third-party tool

Content Migration

Page 30: So you’re building an intranet

Audience targeting is not the same as security

Do you want to target content to specific audiences? Can make users more interested in the site

because they only see relevant content Can also anger people if they want to see

content and feel like they were excluded in any way

What are the rules for setting up those audiences?

Will content owners take the time to actually target content?

Audience Targeting

Page 31: So you’re building an intranet

Planning your Infrastructure

Page 32: So you’re building an intranet

On premises Hosting Company BPOS

Hosting

Page 33: So you’re building an intranet

How many servers of which type? (Web front end, application server, database server)

Do you have a development environment? Staging?

Is your hardware virtualized or not? Will you be extending the site’s availability

outside the firewall? Alternate access mappings VPN access

Will you be applying security certificates to the site?

Server Architecture

Page 34: So you’re building an intranet

If you’re hosting in-house, do you need to order more hardware?

Do you have the appropriate software licenses?

What will the URL(s) for your site be?

Plan Ahead

Page 35: So you’re building an intranet

SharePoint Server 2010 supports authentication methods that were included in previous versions and also introduces token-based authentication that is based on Security Assertion Markup Language (SAML) as an option.

Supported authentication methods: Windows Forms-based authentication SAML token-based authentication

Authentication Types: Classic-mode Claims-based

Authentication

Page 36: So you’re building an intranet

What is right for me? Classic mode

This is the same as used in 2007 Kerberos is still used No support for Forms or SAMAL Token-based

authentication Claims-based

What am I doing Who is my customer

Authentication cont.

Page 37: So you’re building an intranet

What is supported under each Authentication Mode Classic-mode or Claims-mode

Windows NTLM Kerberos Anonymous Basic Digest

Claims Only Forms-based authentication (using)

LDAP SQL database or other database Custom or third-party membership and role provider

SAML token-based authentication (using) AD FS 2.0 Windows Live ID Third-party identity provider LDAP

Authentication cont.

Page 38: So you’re building an intranet

Best Practice Guidance Claims-mode

Only if you have a need for one of the following Forms-based authentication SAML token-based authentication

Classic Use it if you don’t have a need for the above

Important: Classic-mode web application’s can be converted to Claims with PowerShell but, Claims-based cannot go back to Classic-mode.

Authentication cont.

Page 39: So you’re building an intranet

Authentication = Are you who you say you are

Authorization = What do you have permission to see and do?

Who has permission to do what in your site? Does everyone get to edit everyone’s content,

or do people get to only edit content within their own department?

Does everyone have permission to view everyone else’s content?

Security

Page 40: So you’re building an intranet

If users are being stored in Active Directory, which system will be used as the user identity management location? SharePoint 2010 now allows for SharePoint to read or to update

AD info. Will users update their own personal profile info?

Who will maintain the user groups? Adding people to SharePoint groups directly is not very scalable

but works for smaller environments (of several hundred users). Benefit: SharePoint administrators don’t need to contact IT people every time a change is made

Simply adding an AD group to a SharePoint group means users are managed within AD. This is helpful if you already have a system for managing users in AD. It’s also more scalable, and ultimately, allows AD to be used for what it’s intended: user management.

User Management

Page 41: So you’re building an intranet

Are there external systems you want to connect to?

How will you authenticate with them? Will you use the BCS? Are you using additional applications like

SQL Server Reporting Services, or Microsoft Project? Does this affect your authentication requirements?

Are you wanted to install any third party SharePoint products, such as imaging/scanning plug-ins, server management tools, etc.?

External Systems and Applications

Page 42: So you’re building an intranet

Ad hoc site creation Delegated site creation Centralized site creation

Sites defined by a feature, site template or definition

Request form for new sites

Site Creation

Page 43: So you’re building an intranet

What is the disaster recovery SLA? Built-in products or third party products? Where are the backups being stored?

Physical Media? Cloud Storage?

Disaster Recovery

Page 44: So you’re building an intranet

Planning Customization and Development

Page 45: So you’re building an intranet

What skillset do you have to build and maintain your solution in-house?

Are you planning on building your solution in-house, or outsourcing the development to someone else?

If so, how will you maintain the application after it has been built?

Development

Page 46: So you’re building an intranet

PROS: Code can be stored in a code-repository, providing

better disaster recovery Repeatability; code can be tested in one environment,

propagated to next Does not customize contentCONS: Requires SharePoint developers Requires investment in development tools (Visual

Studio) and development hardware.

Bottom line: Good approach for enterprise solutions.

SharePoint Development

Page 47: So you’re building an intranet

PROS: Easy to use. Don’t have to be super-technical to use it. Little development effort. Cheap way to create a nice-

looking site.CONS: Making changes directly to content database

Must make changes directly to production database Cannot test changes in lower environment. Changes must

be made again in production, all over again Customizes content

Bottom line: Good for small sites with limited technical expertise on staff, provided a good disaster recovery plan is in place.

SharePoint Designer

Page 48: So you’re building an intranet

Investing in People

Page 49: So you’re building an intranet

“Train the Trainer” “Champion” or site administrator trains

others in department; delegated training Online or contextual training Lunch-n-learns, etc.

Training

Page 50: So you’re building an intranet

What type of team do you have to support the environment?

What type of SharePoint administration training needs to take place before taking over the day to day management of the system?

Administration Needs

Page 51: So you’re building an intranet

Who is responsible for the ongoing support of the site, once the initial training has been completed?

Are you going to use an existing Help Desk/ticketing system?

Are current Help Desk folks prepared to support SharePoint?

Is there an SLA in place for resolving issues?

Ongoing Support

Page 52: So you’re building an intranet

Wrap Up

Page 53: So you’re building an intranet

How are you going to celebrate the launch of a FANTASTIC intranet site that knocks everyone’s socks off?

Where’s the Party?

Page 54: So you’re building an intranet

SharePoint Server 2007 Best PracticesBill EnglishMicrosoft Press

Association for Information and Image Managementwww.aiim.org

Essential SharePoint 2010: Overview, Governance, and Planning(Addison-Wesley Microsoft Technology Series

Helpful Resources

Page 55: So you’re building an intranet

This is a time to ask questions, or to share with others in the room about your own experiences of building an intranet.

What worked?What didn’t?

Questions and Answers