There are fundamental
concepts in SharePoint that are key to truly understanding the platform.
Every portal, team site, workspace, Internet page, and extranet site is
based upon these building blocks:
Web applications.
In IIS, a Web application is comprised of an Internet Information
Services (IIS) site with a unique application pool. While not a
technically perfect definition, you can think of a Web application as a
URL like http://my.intranet.com or http://sharepoint.intranet.com.
Sites.
A site consists of a data repository, visual elements, administration,
and almost every other core element of the functionality and experience
for the user. Visually, a site is represented as one or more Web pages,
lists, and Web Parts.
Site Collections.
A Site Collection consists of a top-level site and its subsites. It is a
logical unit for administration: There are settings that can only be
configured at the Site Collection level (in other words, at the
top-level site). Each Web application can host many Site Collections.
Lists.
A list is a data repository that can hold columns of data and/or
documents. The objects stored in a list are called items. Visually, a
list is represented by views or a Web Part. It is analogous to a
database table or Excel worksheet.
Items.
Items are the fundamental data objects that are stored within a list.
An example of an item might be a contact, a task, or a document. Items
are analogous to rows within a database.
Site templates.
A template defines what the site will look like, what lists comprise
the site initially, how publishing will work on the site, and a number
of other settings. It enables a site to be created via self-service
using a precreated definition. You can think of a site as a cookie
(that you eat) and a template as the cookie cutter.
Service applications. Each service application provides a set of capabilities to one or more Web applications.
Sites and Site Collections
Sites are the
cornerstone of SharePoint’s infrastructure, which allow individuals or
teams to store, share, and alter structured and unstructured content in a
single environment. Sites also enable organizations to quickly share
information across organizations as well—for example, a regular
communication with suppliers, partners, or customers.
Sites are not a new concept
to SharePoint users. WSS 3.0 and Office SharePoint Server 2007 both had
site templates to support a number of business scenarios, including
virtual teams, custom applications, and aggregation portals. SharePoint
2010 has extended the use of sites by introducing added features and
functionality to enhance the experience for site members.
For those not familiar
with the previous version of SharePoint, sites are containers that allow
you to store lists and libraries of information. These lists and
libraries can store documents, lists of data, and other information.
Think of a site almost like a file share combined with a database, but
with lots of additional features such as a Web-based user interface
(UI). The content that you store may include documents, hyperlinks,
customized lists, contacts, and lots of other types of information. The
value of a site is measured at three levels:
Individual.
An individual can leverage a team site as a single repository for all
team-related material. It is the place to go to get up to speed if the
individual joins the team mid-project, and it is the one place to go to
add or access the content generated by the team. An individual can be a
contributor to all, some, or none of the content. Security associated
with the site, from the page down to the content group (or Web Part), is
managed by the Site Administrator.
Team.
Teams can leverage a team site as a means of sharing without using
e-mail or other methods. Document libraries have version control to
monitor changes as well as check-in/check-out to ensure there is always
only one active version of a document. Geographically dispersed teams
don’t have to struggle with how to share their work.
Organization. All
members of an organization can leverage the information within a team
site by allowing direct access to all exposed team content. Because
sites are template-driven, organizations can ensure that all project or
product sites are organized in the same manner; thus giving users a
consistent look and feel and a quicker path to finding relevant content.
In SharePoint Foundation 2010
and SharePoint Server 2010, everything starts with a site. To explore
the concepts of SharePoint, let’s start with a simple example comprised
of a single Web server and its logical elements (see Figure 1).
At the highest level, you have a physical server running Internet
Information Server (IIS). Within IIS, you have a Web application, which
maps to a URL (such as http://myportal),
a port (such as 80), and an IP address (such as 192.168.1.4). Once a
Web application is extended with SharePoint functionality, one or more
top-level sites can be created. Each top-level site can contain one or
more child sites. The collection of sites that includes a top-level site
and all of its decedents down to the leaf site(s) is called a Site Collection.
This is important, given that much of SharePoint administration
(quotas, backup and restore, permissions, Web Part access, and so on) is
based on the Site Collection concept.
After you determine which
sites your solution requires, the next step is to plan how these sites
and portals are implemented across Site Collections. A Site Collection
is a hierarchical set of sites that can be managed together. Sites
within a Site Collection have common features, such as shared
permissions, galleries for templates, Content Types, and Web Parts, and
they often share a common navigation. All sites in a Site Collection are
stored together in the same SQL database. A portal site is often
implemented as a Site Collection with the top-level Web site as the home
page of the portal.
In general, we recommend that
you put each of the following types of sites in separate Site
Collections right from the start. This will help you manage Site
Collections and content databases better in the long run.
Intranet portal sites
Extranet sites
Team sites related to a portal site or Internet site
My Sites (by default, each my site is a Site Collection)
Internet sites (staging)
Internet sites (production)
Lines of business within a conglomerate
Document Center sites
Records Center sites
So for example, if you
were to deploy a company intranet, a corporate Internet-facing site,
and a records management repository, you’d want to create three Site
Collections from the beginning. This enables you to manage the Site
Collections individually, provide separate content databases, and more
easily accommodate growth over time.
The downside of multiple Site Collections is that there are some features that do not work across
Site Collections. This is important because a large deployment of
SharePoint will dictate multiple Site Collections. The following
features do not work across Site Collections:
Content Types.
How common documents, forms, and other content is normalized in your
organization. (Note: In SharePoint 2010 there is the notion of
Enterprise Content Types that can be syndicated across Site
Collections.)
Content by Query Web Part. This Web Part aggregates information from across sites but does not work across Site Collections.
Workflow. When you deploy workflow, it is only accessible within the Site Collection it is deployed in.
Information management and retention policies.
Records management policies are set at the Site Collection level,
forcing organizations to deploy the same policy multiple times for large
enterprises.
Quotas.
You should absolutely define quotas so that users are used to limited
storage from day one; also configured at the Site Collection level,
which means that you will need to configure quotas separately at each
top-level site.
Let’s say you decided to
create two Site Collections for project workspaces: one Site Collection
for IT and one Site Collection for finance. Due to the Site Collection
limitations just described, if you wanted consistent document metadata
properties on a particular document type, you’d have to deploy the
Content Type twice—once for each Site Collection.
So far, all of
this is true for both SharePoint Foundation 2010 and SharePoint Server
2010 deployments. When you install SharePoint Server 2010 over and above
SharePoint Foundation 2010, several additional capabilities are added
to all sites—additional Web Parts, additional templates, and more
features, some enabled by service applications.
There are several ways to
create new sites. You may want users to ask IT to create sites on their
behalf. Or, you may want to let users create their own top-level sites
directly. Either way, you’ll want to configure self-service site
creation in Central Administration appropriately. Simply go to
Application Management → Configure Self-Service Site Creation and select
either On or Off (see Figure 2).
For users to create top-level sites, they need to go to http://your-Web-application/_layouts/scsignup.aspx (see Figure 3).
This page works in both SharePoint Foundation 2010 and SharePoint
Server 2010, enabling users to create top-level sites and only works for
users if you’ve enabled self-service site creation.
Note
For those of you familiar with SharePoint 2007’s site directory template, this template is hidden in SharePoint Server 2010.
As a user, if you have
Silverlight installed, you’ll get a fancier menu than if you don’t. With
Silverlight installed, you see a section for template selection that
contains multiple categories: Blank & Custom, Collaboration, Content
& Data, Search, Tracking, and Web Databases. The most popular group
is the list of Collaboration templates. The last item in the list is
Team Site, while most of the others are Workspaces. Team sites and
workspaces are very similar, with the concept that team sites are
long-lived and used by teams, while workspaces are shorter-lived and
geared toward a specific work task. But in the end they are pretty much
the same because they are based on the same underlying site definition. Figure 4
shows the site creation page, where you can simply supply a site title
and URL name to complete the creation process. By selecting More
Options, you can add a description, set a specific security permissions
model, and specify navigation options (see Figure 5).
Note
SharePoint sites may not include the following characters:
\ / : * ? ” < > | # { } % & <TAB>.
The following characters cannot be used in the naming of files to be uploaded to SharePoint:
“ # % & * : < > ? \ { } | ~ _
SharePoint file names cannot exceed 128 characters in length.
Figure 6
shows the newly created team site. By default, the site contains no
underlying data within its lists and libraries and hosts a few default
Web Parts on the home page. If the site inherited security from the
parent (this is the default), the list of site users matches the parent,
and the site creator is the Site Administrator and the only person who
can access the site.
|
What’s the difference between a site and a page? A site is a SharePoint container that holds lists, libraries, permissions, and some settings. A page,
on the other hand, represents a single item (a Web page, actually) that
enables a user to see one or more visual elements such as a collection
of Web Parts. For example, a site may contain a document library and a
discussion list. A page, on the other hand, is a single .aspx file (such
as default.aspx or home.aspx) that lives within the site, typically in
the pages library, which lets you visually see the information from the
lists within the site. For each site, you can create as many pages as
you’d like (although many sites just have one page).
|
To
add additional users to the site, use the Site Actions context menu and
select Site Settings. The first Column is Users and Permissions. Click
Users and Groups to add more members.
Let’s look at how the default
presentation of a team site is organized. The left-side navigation
gives users quick access to specific lists (things like document
libraries, custom lists, and calendars). The main body of the page
contains Web Part zones (or placeholders for Web Parts). Additional Web
Parts can be added by using the context menu associated with Site
Actions and selecting Edit Page. Note that you will need specific
permissions on the site to do so. Figure 7
shows a team site in Edit mode. There are boxes around Web Parts that
allow for drag and drop into other Web Part zones. You can also choose a
Web Part by selecting Insert → Web Part from the ribbon, which allows
you to introduce a new Web Part from the Web Part gallery.
A team site is an
effective way to organize content and people around a specific
objective. The value is measured not just during the life cycle of the
site, but for some time after as other virtual teams can leverage the
information captured in the environment to better accomplish their
goals.
If additional containers of information below existing sites are needed, users can create subsites (or sites that are contained within a parent site) by choosing Site Actions → New Site. This will create a site hierarchy.
