Wiley 978-0-470-09941-4 Datasheet

Wiley 978-0-470-09941-4 Datasheet
Chapter 1
Getting to Know SharePoint
Figuring out licensing requirements
Discovering SharePoint’s role in your organization
Deciding which projects to start with
Getting ready to implement SharePoint
Identifying the technologies that enable SharePoint
In This Chapter
f you believe everything you read on the Internet (and who doesn’t?), you
know that SharePoint is either an over-hyped Microsoft product with no
real business value or it’s the next Messiah in information and knowledge
management. So, which is it? Only you can answer that question.
SharePoint’s usefulness in your organization is determined by whether
SharePoint has a role in your existing information systems environment. To
determine SharePoint’s role, you really have to understand what SharePoint
is and what it does. However, simply having this knowledge doesn’t guarantee you a successful SharePoint implementation. However, it does give you a
strong foundation, which is what this chapter is all about.
Understanding SharePoint Technology
SharePoint is a family of technologies from Microsoft that provides a server
infrastructure to support the needs of information workers and their employers.
These needs include collaboration, knowing who’s online, document storage,
and the ability to inform and be informed. The companies that hire information
workers need to audit, monitor, organize, retain, and protect information.
SharePoint makes it possible for companies to engage all their information
workers through the tools people are using already — Office clients (such as
Word and Excel), Internet browsers (such as Internet Explorer), and e-mail
clients (such as Outlook). Obviously, SharePoint works best with Office 2007.
Whether you’re using Office 2007 or OpenOffice, SharePoint gives employers
a means to connect with workers where they work — at their desktops.
Part I: Setting Up SharePoint
By reaching workers where they work, companies can use SharePoint as a
key component for implementing new strategic initiatives and internal communications plans. Beyond sending blast e-mails and convening one-time
town hall meetings, companies can use SharePoint to integrate information
about campaigns, achievement of performance objectives, and company
news into workers’ daily routines. Sound like information overload? It need
not be. SharePoint makes it easy to target content so that people see only the
information that’s relevant to achieving their objectives.
With SharePoint, companies can create a managed information environment
that isn’t centrally managed. Yes, it’s secure, protected, and audited, but
workers make decisions about how information is organized. If workers
change their minds about the organizing structure, it can be changed easily.
By evaluating the ways that employees set up their work environments in
SharePoint — where they store documents, the properties they affix to documents, and with whom they’re collaborating — the information environment
created in SharePoint can provide companies with valuable feedback. When’s
the last time your information environment told you how many Word documents pertained to a particular customer account or product? You can get
that kind of information from SharePoint.
SharePoint also provides workers with the ability to connect with each other.
Instead of sending files back and forth via e-mail, workers can set up information environments that make it easy to collaborate on documents or share a
SharePoint uses a Web site infrastructure to deliver the bulk of its features.
Users can use a Web browser or familiar Office clients, such as Word and
Excel, to access SharePoint’s features. Office clients enable information workers to use familiar tools in new ways, which reduces training and support
costs and increases solution development opportunities. SharePoint offers
organizations a much faster return on investment because SharePoint fits
neatly into most companies’ existing technology infrastructures.
SharePoint isn’t a new technology. The ability to provision team sites for use
with Office clients was first introduced in May 2001 (as shown in Figure 1-1)
with a product called SharePoint Team Services. SharePoint Portal Server
2001, a product for connecting team sites, was released in June 2001. With
each subsequent release, more and more features were added. Windows
SharePoint Services (WSS) version 3, which was released in November 2006,
represents a major re-architecting of the product.
Starting with the 2003 release, WSS became a component of the Windows
Server operating system. The portal product, SharePoint Portal Server 2003,
released alongside Office 2003. The latest release, Microsoft Office SharePoint
Server (MOSS) 2007, is now officially part of the Microsoft Office suite of
Chapter 1: Getting to Know SharePoint
SharePoint Release Timeline
Team Services
v1.0 releases
with Office XP
WSS v2.0
June 2001
May 2001
WSS v3.0
November 2003
June 2003
Portal Server
2001 releases
January 2007
November 2006
Portal Server
2003 releases
with Office 2003
Microsoft Office
Server 2007
releases with
Office 2007
SharePoint Support Schedule
STS v1.0
Mainstream Extended
Support Ends Support Ends
May 2001
July 2006
SPS 2001
July 2006
July 2011
WSS v2
July 2008
July 2013
SPS 2003
Nov 2009
January 2014
MOSS 2007
April 2012
April 2017
Figure 1-1:
In the days of client/server applications, an application commonly consisted
of a relatively short stack of technologies. A Windows application might be
written in a programming language, such as Visual Basic, that accesses a
database on a database server. As long as you had network connectivity and
your database was up and running, probability was high that you could use
the application. More importantly, installing, supporting, maintaining, and
troubleshooting the application was relatively easy.
In the same way that today’s information workers don’t work in isolation, neither can SharePoint. To support the needs of workers and their employers,
SharePoint requires a relatively high stack of technologies. Understanding
SharePoint’s technologies in broad terms is important because this knowledge helps you do the following:
Identify opportunities for reuse and customization: When you gain an
understanding of the technologies SharePoint uses, you can leverage some
of your existing infrastructure. You don’t have to start at square one. Also,
you can extend SharePoint to find new ways to use the infrastructure.
Troubleshoot SharePoint: You’ll encounter many points of failure
in SharePoint — and discover that many aren’t actually part of the
SharePoint software proper. By understanding how SharePoint works
and which technologies SharePoint uses, you can develop a systematic
approach to troubleshooting.
Part I: Setting Up SharePoint
Understand the skills necessary to implement and support SharePoint:
SharePoint requires a lot of skills, and it’s not likely that you have all of
them. I know I sure don’t. You have to make arrangements to acquire the
skills you don’t have in-house.
The SharePoint family of technologies consists of several products. In this
book, I focus on the two primary SharePoint products: Windows SharePoint
Services (WSS) and Microsoft Office SharePoint Server 2007 (MOSS). Each of
these products has a different role in the stack of SharePoint technologies.
See the section, “Licensing SharePoint,” later in this chapter, for a complete
rundown of all the products available in the SharePoint family.
Laying the foundation
The core product in the family of SharePoint technologies is Windows
SharePoint Services (WSS). Because WSS is the foundational product,
no other product in the SharePoint family is possible without it.
WSS is a full-blown ASP.NET 2.0 Web application, which means it runs hosted
inside ASP.NET. When you install WSS, you have to install ASP.NET and everything it requires to run, including the following:
Internet Information Services (IIS) version 6 or 7: This is Microsoft’s
Web server, which is used to host SharePoint. Most typical SharePoint
usage scenarios can configure IIS from within SharePoint. You don’t have
to manage IIS directly very often.
.NET Framework version 2.0 and 3.0: This is a set of software that
installs ASP.NET and Windows Workflow Foundation (WF). After you
enable ASP.NET 2.0 on the server, you don’t have to do anything else
to configure .NET.
SQL Server 2000 or later: This is Microsoft’s database management
system. SharePoint can create all the databases it needs, or you can
create them yourself. You’re responsible for managing backups of
your data.
Windows Server 2003 or later: This is Microsoft’s server operating
system. Monitor the servers that host SharePoint just like you would
any server.
I walk you through installing these technologies on your server in Chapter 2.
Figure 1-2 shows the stack of technologies required to run WSS. Note that
these are logical servers. Your implementation may include several physical
Chapter 1: Getting to Know SharePoint
Windows SharePoint Services
Database Server
SQL Server
.NET Framework
Figure 1-2:
requires Web Server
technologies. Operating System
Windows Server 2003
ASP.NET is the Microsoft platform for building Web applications. A Web
application is more sophisticated than a Web site, which may only display
information. Web applications can provide services, such as electronic commerce. Much of the ability to customize and extend SharePoint comes from
ASP.NET 2.0.
You can think of the technologies listed in Figure 1-2 as SharePoint’s enabling
technologies. SharePoint requires these technologies in order to function
properly. SharePoint integrates with many other technologies to provide
extra functionality, such as Microsoft Exchange Server. See Chapter 9 for
more information on such technologies.
WSS provides the core set of services consumed by all products in the
SharePoint family, especially MOSS 2007. These services include the following:
Data storage and content management: WSS provides lists and libraries
as structures for storing data. Lists are primarily used to store tabular
data, whereas libraries store files. WSS provides a robust set of services
for managing the data and files stored in lists and libraries, services that
allow you to do the following:
• Associate metadata with list items and files (see Chapter 7).
• Create versions of list items and files (see Chapter 15).
• Check out files for editing (see Chapter 15).
• Index sites, lists, and libraries for searching purposes (see
Chapter 14).
Part I: Setting Up SharePoint
What’s in a name?
When someone says SharePoint, what does he
mean? Is he referring to a specific SharePoint
product or the whole kit and caboodle? The only
way to know for sure is to ask him. Although,
don’t be surprised if you don’t get a straight
answer. With SharePoint, you inevitably
encounter an abundance of hype, misunderstanding, and uncertainty. Generally speaking,
when someone says SharePoint, I find he usually
means whichever SharePoint product is most
relevant given the context of the discussion, or
he’s just referring to the SharePoint technologies. Many people genuinely don’t know.
Although I hate to add to the confusion, I find
that constantly referring to a specific SharePoint
product, such as WSS or MOSS 2007, is equally
confusing. Because most people don’t know the
difference between the two products, I usually
just use the term SharePoint. In most cases,
WSS can be used in many of the same ways as
MOSS, so referring to them generically usually
is technically correct. For example, both WSS
and MOSS have document management features. (The MOSS features just expand on those
found in WSS.) Similarly, MOSS has some very
specific built-in features for business intelligence. However, that doesn’t mean that you
couldn’t use WSS for business intelligence.
In this book, I try to be specific about which
product I’m referring to, especially when I’m
talking about MOSS 2007. I often use the generic
term SharePoint any time I’m referring to WSS
or any feature that’s available in both products.
• Manage content approval (see Chapter 15).
• Use list items and libraries in a business process (See Chapter 8)
WSS includes many specialized kinds of lists and libraries that you can
use to perform certain tasks. See Chapter 4 for a complete run-down of
the lists and libraries you encounter in SharePoint.
Web platform and site model: All SharePoint’s features are delivered
via a hierarchy of Web sites. It takes only a few mouse clicks to generate
sites with SharePoint’s site provisioning model (see Chapter 4).
SharePoint generates a full-featured Web site based on an XML configuration file. (WSS includes many of these configuration files that allow
you to create a variety of SharePoint sites to suit the needs of your
business. You can also customize the files or create your own.)
Because SharePoint is an ASP.NET Web application, SharePoint is an
excellent platform for delivering Web applications that include a Web
part framework, navigation, and dynamic form and page generation.
SharePoint gives you a viable alternative to building ASP.NET Web
applications from scratch.
Security: SharePoint provides a security-trimmed user interface so that
users see only the options they have permissions for. SharePoint uses
groups and roles for granting access to secure content, and virtually
everything in SharePoint is securable. The most common authentication
Chapter 1: Getting to Know SharePoint
scenario for SharePoint is Active Directory, although SharePoint supports
custom authentication schemes (such as forms-based authentication) as
well. See Chapter 6 for more details on SharePoint’s security features.
Management: SharePoint provides a multi-tiered administration model
that makes it possible to isolate technical administrators from sensitive
content. Administrators can’t see the files and other content that information workers save in SharePoint sites. Additional administration features include auditing, monitoring, and backing up and restoring tools.
SharePoint provides specialized administration Web sites. All administrative features are also accessible from the command line and via code.
Chapter 18 walks you through accessing the SharePoint administrative
Services: A number of services are provided by SharePoint that support
SharePoint’s other core services. These include notification services,
such as RSS feeds, alerts, and inbound e-mail (see Chapter 10). WSS
indexes all list, library, and site content so these items can be searched
(see Chapter 14). SharePoint also provides migration tools to assist with
deploying SharePoint.
Application programming interfaces (APIs): SharePoint has a powerful object model and Web services. Everything you can do from the
SharePoint user interface uses SharePoint APIs; thus, you can write
code to access all SharePoint’s features. SharePoint makes available
numerous before-and-after events that make it possible to customize
SharePoint’s default behavior.
Kicking it up a notch
Given that WSS is an application platform, it makes sense that Microsoft has
released several products that are built upon that application platform. MOSS
2007 is one such product; it’s essentially a WSS application.
As a WSS application, MOSS consumes WSS resources and extends WSS to
provide completely new features. Similar to how WSS consists of a set of
services, MOSS adds the following services:
Core services are the foundational features that enable MOSS 2007
applications. Core services of MOSS 2007 include personalization,
search, business data catalog, and Excel Services. MOSS 2007’s core
services are shared services because they’re shared across an entire
SharePoint deployment.
Application Services are the building blocks for creating applications in
MOSS 2007. Examples include dashboards, workflows, and user profiles.
These services are mixed and matched to provide a myriad of MOSS
2007 applications.
Part I: Setting Up SharePoint
MOSS combines the services of WSS, along with its own core services and
application services to create MOSS 2007 applications (see Figure 1-3). MOSS
2007 includes the following SharePoint applications right out of the box:
People &
Microsoft Office SharePoint Server 2007
Figure 1-3:
MOSS 2007
Data Storage
& Content
Web Platform
& Site Model
Windows SharePoint Services
Operating System
Portals are an essential user interface feature of SharePoint and are used
to aggregate content, highlight featured content, and provide access to
other SharePoint resources (see Chapter 11).
Enterprise content management consists of document and records
management (see Chapter 15) as well as Web content management (see
Chapter 16). WSS also provides document management, but MOSS adds
to those features with information management policies and document
information panels. I like to think of Web content management as MOSS’s
publishing feature. Web content management makes it possible to publish content to a site that’s intended to be read by many people.
People and personalization encompasses all the features related to
managing user profiles, targeting content to audiences, and personalizing portal content. See Chapters 12 and 13.
Enterprise search provides the ability to index all content within
SharePoint and content outside SharePoint. Search is configurable so
that you can manage the relevancy of results delivered to users. See
Chapter 14.
Business process integration provides the ability to integrate data from
outside sources with SharePoint (see Chapter 17). MOSS can render
InfoPath forms in the browser to automate business forms (see Chapter 8).
Business intelligence provides support for reports, dashboards, and
Excel Services (see Chapter 17). Excel Services creates server-side versions of Excel spreadsheets and renders them in a Web page.
Chapter 1: Getting to Know SharePoint
Chances are your company doesn’t rely on just one of these applications. In
reality, you combine features from each application to meet your business’s
needs. For example, your SharePoint implementation might be 75 percent
document management and 25 percent business intelligence. Conversely, you
might build your own SharePoint application by using the building blocks of
WSS. If Microsoft’s Office developers can do it, so can you!
Licensing SharePoint
Figuring out which features go with which product is challenging. In this section, I explain the official products in the SharePoint family and what it takes
to license them. Pricing varies depending on the kind of licensing agreement
you have with Microsoft.
All SharePoint deployments require Windows Server 2003. WSS version 3 is
part of Windows Server 2003, so you don’t have to buy separate licenses for
WSS. You can download WSS from the Microsoft Web site.
MOSS 2007 products are available for purchase only through volume licensing agreements; you can’t buy them via retail channels. Microsoft offers several types of volume licensing agreements. The pricing associated with each
agreement varies depending on the number of desktops in your organization,
the benefits you receive, and whether you pay up-front or a certain amount
each year. See the Microsoft Products Licensing Advisor at www.microsoft.
com/licensing/mpla for assistance with choosing a licensing agreement.
Properly licensing MOSS 2007 requires a combination of server licenses and
Client Access Licenses (CALs). A server license allows you to run the software, such as MOSS 2007, on your server. Clients need a CAL to access the
server’s features. Two types of CALs are used for MOSS 2007:
Base CAL allows clients to access the portal, personalization, search,
and enterprise content management features of MOSS 2007.
Enterprise CAL allows clients to access the business intelligence and
business process integration features of MOSS 2007 (such as the Report
Center, Business Data Catalog, Excel Services, and InfoPath Forms
If you want users to access the features provided by the Enterprise CAL, you
must also purchase a Base CAL. You need to provide an Enterprise CAL to
only those clients who need to access the advanced services.
You have the option to buy a separate CAL for each user or device. Talk with
your software acquisition professional for advice on which approach best
suits your organization.
Part I: Setting Up SharePoint
Several additional SharePoint products go beyond MOSS 2007:
MOSS 2007 for Search Standard Edition: This server license offers
small- to medium-sized businesses all the features of Office SharePoint
Server Search. The number of indexed documents is limited to 500,000.
MOSS 2007 for Search Enterprise Edition: This server has no limit to
the number of documents that can be indexed with this edition.
MOSS 2007 for Internet Sites: This server license entitles you to use
MOSS 2007 for Internet-facing Web sites that are accessed by nonemployees. No separate CALs are required.
In addition to Windows Server 2003, you may need to implement the following:
Microsoft SQL Server: All SharePoint content is stored in a back-end
database. WSS installs with an internal database; however, you likely
want to use SQL Server 2000 with service pack 4 or higher or SQL Server
2005 with service pack 1 or higher.
Microsoft Internet Security and Acceleration (ISA) Server: To ensure
that remote users are accessing SharePoint in the most secure fashion,
implement ISA Server or a similar product. ISA Server has automatic
configuration tools for protecting SharePoint.
Microsoft ForeFront Security for SharePoint: ForeFront protects your
SharePoint server from malware, viruses, and enables compliance with
content policies, such as prohibiting the use of profanity in documents
saved to document libraries. If you choose not to use ForeFront, you
need some kind of anti-virus solution.
Microsoft Exchange Server: Microsoft’s premiere e-mail and collaboration platform integrates with SharePoint search. Although Exchange and
SharePoint play nicely together, you can use any e-mail server to send
e-mail to SharePoint.
Office Live Communications Server: Enables presence information that
lets users know who’s online and instant messaging in SharePoint with
Communications Server.
Office 2007 Groove Server: Access SharePoint resources during realtime collaboration sessions with Groove Server.
Obviously, Microsoft wants you to run out and upgrade all your desktops to
Office 2007. And while you’re at it, you might as well install Vista, too. The
truth of the matter is that, although your users will certainly have the best
experience with Office 2007, you can work just fine with Office 2003. You can
use previous versions of Office and even non-Office applications with
SharePoint. See Chapter 9.
To customize SharePoint, you need either SharePoint Designer 2007 or Visual
Studio 2005.
Chapter 1: Getting to Know SharePoint
SharePoint’s Role in Your Company
Although understanding the technologies that enable SharePoint and
SharePoint’s features is important, I believe that understanding how SharePoint
fits into your existing information systems environment is even more valuable
than understanding all the SharePoint features. Just because SharePoint can
be used for a certain purpose, doesn’t mean that your organization will find it
useful. I believe that understanding SharePoint’s role in your organization is
key to making the business case for implementing SharePoint.
An information systems environment is the mix of software, hardware, and
manual processes within a company. In some cases, deciding to use SharePoint
is easy because SharePoint solves an obvious problem. For example, you can
use SharePoint to automate business processes by using electronic forms.
However, I find that most companies intuitively think they need SharePoint
but can’t quite figure out the arguments for why.
All the information found in an organization’s information systems environment
are the company’s information assets. Typically, we think of assets as tangible
items of value, such as equipment and land. Information (such as how well the
company is performing and who the company’s top five competitors are) may
be intangible, but I think most people agree they’re of value to the business.
Most organizations have many disparate repositories for storing their information assets. Some repositories are easier to manage than others. Listed
here are some information assets and where they’re commonly stored:
General business transactions are stored in custom and off-the-shelf,
line-of-business applications.
Department-specific transactions are stored in departmental software
applications and tools.
Documents, spreadsheets, and images are stored in a user’s My
Documents folder and network shares.
Directions, instructions, and reference materials are stored in threering binders.
Cheat sheets and calendars are stored on cork boards.
Archived files are stored on CDs and storage boxes.
Protected documents are stored as PDF files.
Links to resources on the Web are stored in a user’s Favorites folder.
Posts from syndicated blogs and Web sites are stored in feed readers.
Musings on life, love, and what’s for lunch are stored in blogs.
Ideas and actionable items from meetings and brainstorming sessions
are stored on notepads, sticky notes, and easel paper.
Part I: Setting Up SharePoint
Sanitized product and company information is stored on Web sites.
Meeting invitations, announcements, and discussion threads are
stored in e-mail Inboxes.
Phone numbers and job titles are stored in a directory, such as
Exchange Server.
Know-how is stored in the heads of employees.
In most organizations, Information Technology (IT) departments are charged
with creating an information systems environment for managing all these
information assets. Databases are a common repository used to manage
information assets. Databases place a structure on information assets that
makes them easier to manage. Even physical assets, such as vehicles and
buildings, are often tracked in databases.
Not all information assets lend themselves well to the kind of structure
required by most databases. These information assets are often saved to
folders on file servers. Because there’s no way to enforce an organization
scheme in file folders, the folders quickly erode into a dumping ground.
Whether you need to manage access to a set of disparate structured assets
or gain more control over less structured assets, SharePoint creates an environment that equalizes the different properties of information assets.
Accessing structured assets
with SharePoint
Structured assets are often found in the formal systems of organizations that
use databases to store their data. Because they use databases, it’s relatively
easy to query and aggregate data from these systems. Line-of-business applications are good examples of repositories for structured assets. Systems for
managing structured assets are usually supported by IT staff and have the
following characteristics:
Formal: They’re the “official” systems of the company, and everyone in
the company can rattle off their names and what they’re used for.
Mature: Because it takes a long time to implement structured systems,
they tend to be predictable and stable. Despite what businesses say
about being innovative and thinking outside the box, an information
systems environment isn’t the place most organizations want to find
Scope: A large number of people often use structured systems. These
are often the systems for which permission is requested as a matter of
course when someone is hired.
Chapter 1: Getting to Know SharePoint
The problem with structured assets isn’t managing the assets; the problem
is managing access to the assets. What makes structured assets so easy to
manage also makes them difficult to access. It’s challenging to teach executives how to log into a system and run reports or to show a large group of
end users how to navigate menus and access a single process, such as entering a purchase order. SharePoint makes it possible to more finely control the
access to structured assets in the following ways:
Customize access to structured applications: Instead of granting large
numbers of users access to enterprise applications when they only need
limited access, you can provide alternative access in SharePoint. For
example, if someone needs to look up lists of data, query the customer
database, or look up a part number, you can make that data available via
Supplement structured applications: You can supplement structured
applications by automating business processes. Oftentimes, an enterprise application encompasses only part of a business process, not the
whole thing. For example, most software has purchase order or expense
report processing. Oftentimes, the request is manual or in e-mail and
must be signed by a manager. You can initiate the process in SharePoint
and then queue the transactions in your primary system.
Link structured data to unstructured data: Commonly, Word documents and spreadsheets support a business transaction. You can link
documents stored in a document repository to transactions in your
structured systems.
Limit access: Create a data catalog in SharePoint to access data for the
purposes of querying and report building.
Consolidate assets: Many times, you need to present an aggregated view
of structured data that comes from multiple sources. SharePoint makes it
possible to provide a consolidated view from multiple back-end sources.
Managing unstructured
assets with SharePoint
Unlike structured assets, less structured assets (such as Word documents)
usually aren’t stored in databases. They’re often stored on file servers and
removable media, such as CDs. Other less structured assets (such as e-mails
and blog posts) may be stored in databases, but the information conveyed by
the e-mail or blog post isn’t managed. Instead, the mail server acts like a file
server, and the e-mail acts like a file.
The problem with files is that they’re hard to manage and control. End
users can easily store them on thumb drives and send them as e-mail attachments. Despite IT’s attempts to control files with policies and backups, files
are slippery.
Part I: Setting Up SharePoint
Contrary to what IT staff want to believe, less structured information assets
are stored in more places than just file servers, such as the following:
My Documents folder
Favorites folder
RSS feed readers
Blog sites
Web sites
Inboxes and other mail folders
Filing cabinets
Off-site storages
Table 1-1 lists some of the less structured assets you can expect to find.
Table 1-1
Common Information Assets
Type of Asset
Word documents
Policy manuals, forms, memos, letters, procedures,
white papers, press releases, contracts, plans, and
Excel spreadsheets
Return on investment, accounting schedules, forecasts, analysis, mailing lists, schedules, and directories
PowerPoint presentations
Sales demonstrations, training materials, and new
hire orientations
Access databases
Departmental databases for tracking contacts and
Meeting requests, discussion threads, notifications
and announcements
PDF files
Archived and protected documents and brochures
Company outings, products, and Web content
HTML pages
Departmental Web sites, self-service portals, and
secure areas of public Web sites
Although repositories for storing structured assets are formal, mature, and of a
wide scope, the environment for less structured assets is often more difficult to
Chapter 1: Getting to Know SharePoint
control. Although businesses don’t want their employees’ sales presentations
to be boring, stuffy, and staid, they do want the environment in which these
documents are created to be manageable. By creating a manageable environment for less structured information, SharePoint confers the following benefits
to less structured assets:
Structure: SharePoint stores everything in a database. As a result, users
can create properties that describe their documents. These properties
can be used to better organize documents. Some of the information
found in documents is better suited for storage in a database table.
Rather than storing the document in SharePoint, users can store the
document’s data in the database.
Standardization: SharePoint allows you to define the kinds of documents and other information (or content types) stored in the database.
When someone attempts to add documents, SharePoint prompts the
user for the set of properties associated with that content type. Using
content types ensures that the same properties are captured.
Share: SharePoint makes the information available in documents accessible to larger numbers of people. Oftentimes, the only way to distribute
documents now is with an e-mail attachment.
Archive: SharePoint allows you to define policies that determine for
how long a document must be archived.
Backup and restore: By keeping less structured assets in a common
repository, SharePoint makes it possible to back up and restore these
Secure: Creating a secure environment means more than just restricting
unauthorized access. SharePoint makes it possible to extend those
restrictions beyond the managed information environment by preventing
unauthorized distribution of assets.
Audit: Part and parcel of securing assets is the ability to audit their access.
SharePoint makes it possible to monitor the information environment for
less structured assets in ways previously not possible.
Summarize, analyze, and mine data: By applying properties to less
structured assets, SharePoint makes it possible to query and search
these assets like structured assets.
Legitimize: By bringing in social tools (such as blogging, RSS, Web,
and search) inside the information systems environment, SharePoint
acknowledges the valuable role these tools play. Organizations don’t
operate in a vacuum. SharePoint extends access to the external environment in a controlled and measured way that encourages productive and
purposeful uses of these resources.
Part I: Setting Up SharePoint
SharePoint as the hub
With the significant investment companies have made already in people and
technology, how can SharePoint possibly have a role in this already crowded
information systems environment? With IT staff overburdened already, it’s
little wonder at the lack of enthusiasm in implementing yet another system.
Despite all the technological advances, the big budgets, and the far-reaching
plans, many end users and members of the business community find themselves increasingly alienated from their company’s information environments.
Most end users can tell you that something is clearly missing. SharePoint aims
to be the missing link in a company’s information systems environment by
acting as the hub, as shown in Figure 1-4. As the hub, SharePoint is an integral
player in providing users access to information assets.
Whereas your current information environment uses file shares, e-mail Inboxes,
and databases as storage repositories for information assets, SharePoint provides its own set of repositories for creating manageable information environments. These organizing containers are organized in a hierarchy. Organizing
them in a hierarchy creates parent-child relationships between containers,
which makes it possible for the settings in a higher-level container to apply to
a lower-level container — a process called inheritance. Using a hierarchy also
makes it possible for administrative tasks to be delegated to administrators of
lower-level containers. For example, a higher-level administrator might choose
to enable a set of features so lower-level administrators can disable those features if they want to.
Whether containers are administered by IT staff, power users, or information
workers depends on how the company chooses to make administrative
assignments. The containers that are often managed by IT include these:
Server farm: Like most server software, SharePoint often requires multiple servers — dubbed a server farm — to work productively. Although
it’s possible to have multiple server farms, most companies only ever
need one. IT is responsible for deploying the server farm and managing
its health. I walk you through setting up SharePoint in a single-server or
server farm configuration in Chapter 2.
Some editions of SharePoint (those based on MOSS 2007) have an additional component — the Shared Services Provider (SSP). The SSP is
responsible for providing services that are required across the entire
server farm, regardless of how many servers you have. Each server farm
usually only has one SSP. See Chapter 2 for details on setting up the SSP.
SharePoint provides special administrative interfaces — Central
Administration and Shared Services Administration — for managing
the server farm and SSP, respectively.
Chapter 1: Getting to Know SharePoint
Web applications: Web applications are most often used to create
an information environment for a single company. If the company is
especially large, IT may choose to create separate Web applications to
separate the company’s divisions. For example, if the company has an
operation in the United States and one in the United Kingdom, IT would
likely create separate Web applications for each. Also, if the company
wants to provide an information environment that will be accessed by
the public, such as vendors or customers, they may choose to separate
that content into its own Web application. I’m sure you guessed that you
can apply some rules for when you should create separate Web applications. I discuss rules for creating Web applications and how to create
Web applications in Chapter 3.
Site collections: Each Web application contains at least one site collection. A site collection can be used to create an information environment
for a single company, or there may be separate site collections for each
division within the company. Similar to Web applications, there are rules
for how site collections are created (see Chapter 3). A site collection
contains at least one top-level SharePoint site, which is used to store and
display information. Site collections are usually created by IT staff, but
their content is often administered by a member of the business staff.
Less structured assets:
Word documents
Excel spreadsheets
PDF files
Structured assets:
Line of business applications
Departmental applications
Web Sites
Figure 1-4:
SharePoint is
environment’s hub.
Part I: Setting Up SharePoint
The containers that are often created and managed by business users include
the following:
Sites: SharePoint sites are usually created for a specific purpose, such
as coordinating a project team or providing an information environment
for a department. It’s common for companies to create sites for each of
the departments within their organization. SharePoint provides a special
kind of site, called portals, which is intended for providing information to
larger groups of people. For example, the top-level site in a site collection
is often a portal. Sites can contain additional sites as well as lists and
libraries. Each site has its own administrative interfaces for managing
permissions, navigation, and appearance. I discuss sites in Chapter 4.
SharePoint sites can inherit permissions, navigation, and appearance
settings from their parent site.
Lists: SharePoint provides a number of predefined lists that can be used
to store data, such as tasks, events, and announcements. You can create
your own custom lists to store data that’s specific to your business. By
default, list data appears in a tabular format, but SharePoint provides
additional view formats. You can easily customize how much data
appears on the screen and whether the data is sorted, filtered, and
grouped. You can even create master/detail displays of data. SharePoint
automatically generates Web pages to add, edit, and display the data
you store in lists.
Libraries: SharePoint sites can contain any number of libraries for storing files. The most common SharePoint library is the document library,
although you can also use libraries to store electronic forms, pictures,
and PowerPoint slides. You can create new file properties for the files
you save in SharePoint libraries. SharePoint automatically prompts
users to enter values for the properties when they upload files. Users
can open files from and save files to SharePoint libraries from their
usual desktop applications, such as Word and Excel.
From SharePoint’s perspective, all the information assets that you store and
manage in SharePoint are content. All the Word documents, Excel spreadsheets,
and PowerPoint slideshows that users upload to libraries are content. All the
tasks, announcements, and other data that users enter into lists are content.
Even the Web pages that are displayed in a portal are content. The sites, lists,
and libraries that you create to display, organize, and store content are content
SharePoint’s content structures are more than just passive storage containers.
To have a managed information environment, SharePoint provides a framework of features that includes workflows, content types, versioning, content
approval, and permissions management. I introduce lists and libraries in
Chapter 4. You can read more about SharePoint’s content management features in later chapters.
Chapter 1: Getting to Know SharePoint
Selling SharePoint
When you make new discoveries about SharePoint’s capabilities, don’t be
surprised if everyone else doesn’t fall in line. You have to see SharePoint to
believe its technologies. That’s why I think it’s so important to ask for a hunting license. Only by taking on a few projects and showing SharePoint’s value
can you start to get people on board.
When you prepare your case for selling SharePoint, keep the following in mind:
Remember your audiences. Be ready to present your business case to
multiple stakeholders many times over your project’s life cycle. You
won’t just sell SharePoint once. Consider the different perspectives of
executive management, operations, technical staff, and end users when
you prepare your case. Each of these stakeholders has a different set of
criteria for evaluating SharePoint.
Get buy-in. If you know ahead of time that a particular individual or
department is a roadblock, court them early and often. If possible, get
them to take a stake early in the planning phases and don’t let people
or departments drop out of this process at any time.
Know your politics. Be aware of the formal and informal power structures in your company. If you think that politics might hinder your project’s success, consider using a consultant. Management is often more
willing to listen to a third party than to an employee.
A common roadblock to implementing SharePoint is the Not Invented
Here syndrome. All companies have people who are entrenched in using
a current process or product that they refuse to relinquish. If that solution was hand rolled — as in the case of a home grown portal solution —
it can be especially brutal to convince people to embrace SharePoint.
Show business value. You have to show your stakeholders how this
project adds value to the business. Again, remember your audience.
To executive management, business value often means financial return.
Operations may see value in a project that streamlines business
processes, whereas ease of use may appeal to a line worker.
Finally, you may very well come to the conclusion that SharePoint isn’t
right for your business. If you have trouble getting people to cooperate with
you, that’s a red flag. You may need to wait until the winds of change come
through. Of course, you’re a shoo-in if you can figure out how to make the IT
manager think SharePoint was his idea.
Part I: Setting Up SharePoint
Getting Started with SharePoint
Having a set of objectives in mind is important when you start implementing
SharePoint. Developing a list of objectives helps you define the scope for
your SharePoint project. Don’t think of your project in terms of “implementing SharePoint.” Instead, state your project in terms of whatever it is that
you’re doing with SharePoint. Here are some good examples of SharePoint
project objectives:
Create secure, version-controlled document repositories for
departments, teams, and task forces.
Move contacts, calendars, and announcements into an easily
accessible site.
Automate the process for submitting business expense forms.
Track documents, events, and tasks related to projects.
Any of these goals are easily achievable with WSS. I suggest that you attack
each of these as a separate phase of your project. Also, narrow the scope to a
particular team or department. Instead of trying to implement all these goals
for your entire organization, pick a single group to act as the pilot. For example, start using document repositories with the Marketing department.
I suggest you start with projects similar to the ones in the preceding list.
Even though document management and team sites are basic features of
SharePoint, many companies are overwhelmed quickly by them. Plan on
spending anywhere from 3–12 months training and supporting users on
SharePoint’s basic features.
MOSS 2007’s My Site feature is a great way to get users introduced to using
SharePoint. If you know you want to implement MOSS 2007, I suggest training
users on My Site first. Each member of the SharePoint portal is the administrator of his or her own My Site personal site. This is a great way to get folks
up to speed on administering SharePoint sites.
After you’re confident that most people know how to save files to a library
and work with lists, I suggest you move on to the basic features of MOSS
2007. Example projects include the following:
Creating a collaboration portal that aggregates content from SharePoint
team and departmental sites.
Implementing a document review or approval procedure for documents
saved in team or departmental repositories.
Archiving documents, e-mail, and other content to a protected records
management repository.
Adding file shares and other content to be searched from within
Chapter 1: Getting to Know SharePoint
Advanced uses of MOSS 2007 include the following:
Integrating data from back-end business databases in lists and libraries
being used by teams and departments.
Creating executive dashboards that display the company’s progress on
key performance metrics.
Converting all manual forms to browser-based electronic forms.
If you want to read about specific companies that have successfully implemented SharePoint, you can visit the Office Solutions Showcase at www.
Choosing SharePoint projects
Deciding where to start with SharePoint is daunting. Most people go with
what’s easy only to find themselves quickly overwhelmed by too many “easy”
projects. Instead of going with whatever jumps out at you, I suggest you sit
down and make a list of candidate projects. A candidate project is any problem
that you think you can solve by using SharePoint. Identifying SharePoint’s role
in your existing information systems environment is a good place to start.
Specifically, you can look for holes in the IS environment or situations where
you need to create links between different kinds of information. For example,
any time you encounter a spreadsheet that’s being used by multiple people,
you probably have a good use for SharePoint.
After you create a list of candidate projects, I suggest you do the following:
Identify the reward level of candidate projects on a scale of 0–100. You
can define reward based on your organization’s values, such as exposure, usefulness, impact, and profile of the project.
Assign the risk level of candidate projects on a scale of 0–100. Identify
risks, such as difficulty, obstacles, political issues, and probability of
Plot the values for reward and risk level on a chart with the numerical
values you assign.
You can make your approach to creating the reward and risk values as scientific as you want. You can best guess the values or come up with an approach
that assigns weights to the underlying characteristics of reward and risk. You
can even use financial analysis, such as internal rate of return and net present value, to assist with your analysis.
Part I: Setting Up SharePoint
I like to plot the values on a scatter chart in Excel with the X-axis values in
reverse order. The graph provides a visual representation of which projects
you should tackle, as shown in Figure 1-5. The quadrants in the graph help
you prioritize your projects, as I describe here:
Quadrant I: Low reward, high risk. These aren’t the projects you want
to start with.
Quadrant II: Low reward, low risk. You can test the waters with this
low-hanging fruit. Implement several of these projects so the rewards
pile up.
Quadrant III: High reward, low risk. Implement one or two projects
from this quadrant and increase your star power.
Quadrant IV: High reward, high risk. You’re betting the farm with these
projects. If you’re unsuccessful, you could be putting the entire
SharePoint implementation at risk. Make sure you have some success to
show from other projects before tackling these.
High reward,
high risk
Low reward,
high risk
Figure 1-5:
Plot your
High reward,
low risk
Low reward,
low risk
Chapter 1: Getting to Know SharePoint
Getting a hunting license
Because every business is different, every SharePoint implementation looks
slightly different. Only you can determine what those gaps are in your information systems environment for SharePoint to fill. When it comes time to
decide which SharePoint features, if any, you should implement and in what
order, I suggest you start out by asking for a hunting license. In other words,
look around your business for opportunities to evaluate SharePoint.
I’ve given some suggestions throughout this chapter for ways that you can
use SharePoint in your business. Even if you know very little about
SharePoint, here are a few rules of thumb for how you can bring your existing
information assets into SharePoint:
Spreadsheets are the easiest candidates for implementing into SharePoint
because SharePoint has so many options. Spreadsheets that have columns
and rows of data are prime candidates to become lists in SharePoint.
Spreadsheets that display schedules, analysis, and charts are often better
displayed as Web content in Excel Services. In both cases, end users can
continue to open the file in Excel and update it.
Another obvious use for spreadsheets is to store them in document
libraries. Although this is better than using a regular file share, it doesn’t
start to unlock the information stored inside the spreadsheet. Instead of
just storing everything as a file in a library, see if the file’s contents are
valuable to the organization as a whole.
Word documents most often make their way into document libraries.
This makes sense if you need to take advantage of collaboration tools,
such as version control, approval routing, and archival policies. You can
also convert Word documents to Web pages. When documents are used
as forms, consider converting them to InfoPath forms. Tables displayed
inside documents are prime candidates to become SharePoint lists.
Documents that describe tasks or business processes may be the blueprints for creating a workflow. Documents intended for consumption by
a large number of people should make their way to the portal’s
Document Center.
PowerPoint presentations can be stored in document libraries.
Individual slides can be stored in a slide library to create a reusable collection of templates and slides for building presentations.
Access databases can be replaced with custom lists and workflows in
Visio diagrams can be stored in document libraries or saved as Web
pages and displayed in SharePoint sites.
E-mails can be replaced with announcements, calendars, and tasks lists
in SharePoint. Instead of sending attachments, users can send URLs to
resources stored in SharePoint.
Part I: Setting Up SharePoint
Image files can be stored in picture libraries. Users can create Web pages
to display the images for everyone to see. Images used for production of
Web sites and other media can be checked in and version controlled in
Paper documents can be scanned and stored in libraries. Paper forms
can be converted to InfoPath forms.
Know-how is what gets done, who does what, when something is done,
why it’s done that way, how it gets done, and where it gets done that
only the people who do a job seem to know. A person’s job- related
know-how is an information asset that can be stored in SharePoint.
By using SharePoint to trigger workflows, store contacts, track tasks,
schedule events, and keep lists, an employee’s know-how can become
a reusable information asset.
SharePoint’s document libraries can be used to store any kind of file, including audio, video, and cad/cam files. The primary limitation of using document
libraries is the file sizes uploaded to the library.
Preparing for SharePoint
Ideally, you’ve already made your business case, and you’ve created a list of
projects and prioritized how you want to proceed. Many planning tasks are
involved in implementing SharePoint. When you start planning your project,
it’s helpful to consider the many roles that are required to implement
Technical people are responsible for installing SharePoint on the
servers and monitoring its health. This also includes database
administrators who create databases and schedule backups.
Solution builders are people with any kind of background who are responsible for using technology to solve business problems. Sometimes solution builders belong to IT staff, but they may also be power users. Solution
builders may use tools like SharePoint Designer to customize solutions.
Developers write code for extending SharePoint or creating custom
Designers are responsible for SharePoint’s look and feel. This could be
as simple as changing the color scheme to completely branding
SharePoint to be consistent with internal policy.
Subject matter experts are most often your business personnel who
understand how your business functions. You may also need to bring in
specialized experts to assist with certain aspects of your project.
Chapter 1: Getting to Know SharePoint
There are many additional roles. Some are part and parcel to projects. For
example, you obviously need a project manager. It’s probably also a good
idea to have a project champion and sponsor to help sell the project throughout your organization. Consider involving Legal to make sure you cover all
your bases as it relates to privacy and terms-of-use agreements.
I like to think of a SharePoint project as using three distinct types of planning.
Each of the following types maps to a group of users who perform the planning:
Technical people must plan your server topology and server farm.
Subject matter experts and solution builders are responsible for identifying the kind of content that must be stored, displayed, and managed
and coming up with the appropriate site hierarchy and building blocks.
Designers are also involved to help manage the look and feel.
Solution builders and software developers are responsible for planning
ways to use SharePoint as an application platform.
I discuss each of these planning tasks required in the rest of this section.
Planning the server farm topology
Technical people are responsible for figuring out your server farm topology.
Only in rare circumstances is SharePoint deployed to a single server. In most
cases, SharePoint requires at least two servers.
Planning the server farm topology requires tasks such as these:
Matching the topology to the project’s requirements.
Determining the requirements for capacity, performance, and availability.
Deciding how many servers are required of each kind of server role.
Figuring out how the servers are configured within the existing network
topology to prevent unauthorized access.
Providing access to authorized and anonymous third parties as required
by the project.
Determining strategies for upgrading and migrating content from previous versions of SharePoint and other server applications.
Identifying requirements for multilingual sites.
Provisioning databases for use by the server farm.
Making sure you have the proper licensing to match requirements.
Creating a backup and restore strategy.
Creating an ongoing administration plan.
Part I: Setting Up SharePoint
Technical folks are also responsible for planning for the deployment of the
server farm. This requires coordination with other planners to ensure that
the deployment occurs in accordance with requirements.
If you don’t have the internal staff to complete this phase of planning, don’t
worry. You have two options:
Hiring consultants: You can hire a third party to come in and take care
of the technical stuff for you. Depending on the size and complexity of
your project, it could take as little as a day to get you up and running.
This option works best for companies who already have an existing IT
infrastructure but don’t have the time or the skill set to bring up a
server farm.
Hosting: If you don’t have the internal staff to support a SharePoint
farm, hosting may be a good alternative. With a hosted solution, a third
party allows you to access SharePoint on their servers. Hosting is a
great way to get up and running with SharePoint in a very short period
of time and for the lowest amount of up-front cash outlay.
Several kinds of hosting options are available. You can find companies
who host only WSS and those who also host MOSS 2007. You must
decide whether you want to use a shared server or a dedicated server.
With a shared server, your SharePoint installation lives alongside other
people’s SharePoint sites on the same server. For the highest amount of
security and availability, you can use a dedicated server that only your
company accesses. Obviously, a shared solution is less costly than a
dedicated solution. If you go with a dedicated server, most companies
let you bring the server in-house whenever you get ready.
Planning for content and usage
Deciding what gets stored in SharePoint and how SharePoint is used in your
organization is the meat and potatoes of your planning. I’m assuming that
you’re just planning on implementing the baseline collaboration and document management features of WSS. In my opinion, this is where you should
start unless you have no intention of using any of these features. These features are the underpinning for nearly every application of SharePoint you can
dream up. For that reason, I think it’s vitally important that your organization
master these uses before you start getting too advanced. Anything beyond
this project, I consider a SharePoint application.
It’s at this planning level that you need to do the following:
Figure out which sites to create and how to organize them in a site
Decide whether to allow inbound e-mail.
Chapter 1: Getting to Know SharePoint
Decide how users will access SharePoint with which kinds of clients.
Decide how to filter content so users see views that are personalized to
their needs.
Determine who gets access to what and who has responsibility for the
various tasks required to maintain SharePoint.
Determine who’s responsible for creating new sites as well as adding
new users and maintaining them.
Decide how users are authenticated to SharePoint.
Determine how SharePoint provides people information such as names
and contact information.
Decide who creates and maintains content structures, such as lists
Identify content and its organization.
Decide who administers all this stuff and keeps it up and running.
A vital piece to your success in this planning stage requires that you provide
adequate training and support. This doesn’t mean just to end users or just to
technical people. Both groups need training and support. Technical people
need to understand how to set up, configure, and administer SharePoint.
When it comes to the day-to-day use, you have to decide whether the help
desk is responsible for providing this support.
Planning for applications
Planning on using SharePoint to solve a specific business problem is the icing
on the cake. The planning process for specific applications depends on how
you plan to use SharePoint in your organization. Regardless of how you plan
to use SharePoint in your business, here are some common planning steps:
1. Identify the project’s goals.
2. Identify the SharePoint features that are relevant to achieving your
project’s goals.
3. Identify the configuration information you need to set up SharePoint.
4. Identify the skills required to implement the features and address any
skill gaps.
5. Create a development process for creating SharePoint applications.
In most cases, implementing an application in SharePoint requires some
kind of development or design work. You need to identify the tools that
are required to complete the task — most often you use SharePoint
Designer 2007, InfoPath 2007, and Visual Studio 2005. Make sure you
have the skills or the outsourcing capabilities.
Part I: Setting Up SharePoint
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF