Getting Started with SharePoint

By: Rob Fisch   |   Updated: 2010-01-20   |   Comments   |   Related: > Sharepoint Design

Problem

After a new installation of SharePoint (MOSS or WSS) I find there is a myriad of objects available. Being new to SharePoint, the combinations of possibilities seem endless. There are site collections, sites, web parts, libraries, lists, content editor web pages, calendars, tasks, discussion boards, wikis...the list goes on and on. How does one put it all together in a way that makes sense?

Solution

The basic overview

SharePoint is collaborative system that provides an environment for organizations to present and receive online content to and from everyday knowledge workers. The entire system is accessible through a web browser. Access to content sections can be controlled dynamically at different permission levels to present different content to different sets of users. The important point is that users (not administrators) are in control of the content that is delivered in a way that is meaningful, immediate and decentralized. Typical examples of content types include documents, lists, tasks, calendars, web pages, graphics, workflow processes, and more.

Understanding a few basic concepts will go a long way toward getting started with SharePoint. This overview will touch on some key concepts to help first time users get a jump start on building SharePoint solutions with the 'out-of-the-box' toolset provided by Microsoft. To begin with, we'll discuss a bit about SharePoint's backend infrastructure. Then we'll explore options on site organization relating to site collections, sites, hierarchies, and concepts about permission inheritance. And finally we'll touch on basic content structures and presentation methods.

Infrastructure

For the most part, SharePoint content is stored in one or more SQL Server databases. (There are some small exceptions to this that are unimportant to this overview.) Some examples of content types include documents, lists, web pages, workflows, calendars, to name just a few. Since the user interacts with SharePoint via the web browser, there needs to be a method of connecting to the database. Fortunately there is and it's completely transparent to the user. The user simply opens the browser and navigates to the SharePoint server URL. The SharePoint server running an IIS web server contains a virtual directory with a series of .asp pages that provide the connection interface to the SharePoint database. The SQL Server can be on the same server as the SharePoint installation, but it does not have to be. And there are some good arguments for having a multi-server environment. The main point is that the user simply connects from their PC, using a web browser to the web server (where SharePoint services are installed). The web server then acts as middle man, connecting the user to the SQL Server where the SharePoint database is located.

Site Organization

Site Collections

SharePoint sites exist within site collections. At a basic level, a site collection is a container that holds a group of sites. Individual sites can have different permission access, but conceptually the site collection exists in single hierarchy. (Think of the typical tree, branch and leaf hierarchy). A site collection exists in a single content database (on a SQL Server) . There can be multiple site collections and multiple content databases. And a single content database can hold multiple site collections, but a single site collection cannot exist across multiple databases. There are a few purposes for breaking up into multiple site collections and databases. One that comes to mind is to keep content databases at a reasonable size for backup/restore purposes. Another is scalability (i.e. the ability to move a particular content database to another set of drives). Still a third reason might be performance (being on multiple drive sets). But this is getting way ahead of this basic overview. I just wanted get across the point that future expandability is possible. To start out, one site collection and one content database is adequate.

Sites and hierarchies

When a Site Collection is created you start out with a single "site" at the top level of the site collection hierarchy.

It's helpful to think of this first page as a splash page, the beginning page to the SharePoint portal where all navigation begins. In addition to general navigation, it can have basic information in common to all users (i.e. company news and/or announcements, featured articles or blogs, top-level company metrics of interest to everyone, etc). It's your SharePoint 'home page'. From here it is likely you will create multiple sites in some sort of hierarchy. These can be by any logical division (i.e. by division, department, location, etc). And each child site can have multiple child sites of their own. There are some reasons to build the hierarchy fairly flat rather than tall. Over time, you will develop your own approach. If you are using MOSS 2007, it is fairly easy to change the hierarchy of sites with a few mouse clicks, not so with WSS3...and might not work at all depending on their size (or at least be difficult), so it's a little more important to plan out the hierarchy early on. The reason is, you can be left with a misaligned hierarchy. For example, let's say your sites are organized by location and then department. And then, for some reason, a department moves to another location. You either have to find a way to move the site or just leave things where they are and fix it with some creative navigation enhancement. It's not a big deal if it happens but it can make things messy.

Content

There are various forms of SharePoint content types. These can be simple web pages, documents (in libraries), various types of lists, calendars and more. Once you learn how to create these things and arrange them in an orderly way, you'll be well on your way to becoming a SharePoint architect. Below are some notes that will help you understand the basic structures of SharePoint and how to put the pieces of the puzzle together.

• User content exists within "sites". You can think of a site as a container to hold various related content types about a particular department, team, project, region, meeting, or other logical grouping. Sites are natural security boundaries and can be displayed dynamically to users based on permission access. Multiple sites can be organized in a hierarchy if needed.

• When creating a new site, you get the option to choose from various templates. These might be helpful in some cases, but I hardly ever use the stock templates. Sometimes I create my own when I need to clone them, but usually I start from scratch with a "blank site". It's the best way to develop an understanding of what's going on.

• The first thing I do after creating a new blank site is to delete the Microsoft Sharepoint logo. (It's also a nice exercise because you get to learn how to clean up things you don't want.) To do that, follow these instructions:

Click on "Site Actions" and then "Edit page"

Then click on the "Edit" dropdown (next to the Site Image title) and select "Delete".

Then click "Exit Edit Mode"

Document Libraries

Most users think of document libraries as an elegant place to keep files (i.e. with a pretty web interface). Nothing could be further from the truth. SharePoint document libraries offer many advanced features not found on a normal file server.

• Content Approval - A feature provided to enable the "approval" of submitted documents by library approvers (a small select group of users in charge of approving content).
• Version History - Provides the ability to save all (or a specified number of) previous versions of a document. The latest version is shown by default. Previous versions are available by selecting the 'version history' of a specific document.
• Workflow functionality - Documents (and other list items) can be routed to specified work teams for feedback and/or approval. The workflows can be customized using a variety of tools (the web interface, SharePoint Designer or Visual Studio) depending on the requirements. Workflows can be based on certain programmed conditions to gain granular control.
• Security options controllable by non-technical staff - Security options can be delegated to non technical (i.e. non IT staff) to allow for decentralized management of resources. All SharePoint security can be achieved using the web interface, requiring no special software at all.
• Metadata (extra columns) for advanced group, sort & filtering options. - Unlike a file system, document libraries can have extra fields, controlled by users, in order to full describe content in many ways. For instance, once a document is uploaded, extra fields can be maintained in order to help other users looking for a resource. Examples might be "Due Date", "Category", "Status", "Project Name", etc. These extra fields can then be used to sort, group and/or filter a library (or list) in helpful ways. At a basic level, these extra columns can be used to help describe the content within a document (without the need to open the document).

Below is a screenshot of a document library grouped by the "Status" field:

(The status field is shown for illustration purposes, to show how the groupings work. In a real environment, it wouldn't be necessary to show, as the sections are already grouped.)

Lists

Lists are great way to track things in a collaborative environment. You can think of them as like little spreadsheets that open in the web browser. They are similar to document libraries, however there is no "document". Though you can have "attachments" in a list item, they appear in a minor way (with a paper clip), and should be thought of as 'supporting' a list item, rather than being the main purpose (as in a document library). Below is an example of a simple list, grouped by one of the fields:

There are many list templates to choose from. Here are the choices from a MOSS 2007 system:

Each list has a slightly different feature set. When in doubt, just choose a "Custom List" and build it up from scratch.

Web Pages

Additional web pages can also exist in SharePoint. These would be hosted in a document library. These can be standard .html type web pages (created externally and then uploaded), or they can even be built using the built-in "Web Part Page". Web Part Pages are generated through the web interface. Creating them and adding content takes absolutely no coding experience at all. In fact the home page of each individual SharePoint site is a special page, much like a Web Part Page, that is automatically created with every new site. Other common out-of-the-box content types are calendars (which have the ability to show a simple Gantt chart), Wikis, Discussion Boards, Tasks, Links, Surveys, Content Editor web part pages (mini iframes with a gui text editor) and more.

Summary

SharePoint contains many objects to choose from. Understanding the basic building blocks will help you in learning to architect a meaning portal for your organization. Take your time and don't be afraid to experiment. It's a good idea to create special testing sites just for design experimentation, before implementing new ideas.

Next Steps

• Getting to the know the feature differences between WSS2, WSS3, MOSS 2007 - Standard and Enterprise.
• Understanding SharePoint security.
• Learn how to use SharePoint Designer.
• Backup and Restore strategies.
• Check MSSQLtips for ideas on supporting your SQL Server infrastructure.

About the author

Rob Fisch has worked with SQL Server since version 6.5 as a dba, developer, report writer and data warehouse designer.

This author pledges the content of this article is based on professional experience and not AI generated.

View all my tips