Let me be the first to
declare, officially, if prematurely, “The file server is dead!” With the release of
Windows SharePoint Services
3.0, Microsoft delivers simple,
secure, and effective support
for collaboration, knowledge
management, and business
processes.
To understand and implement SharePoint Services 3.0
and get a feel for some of its
key new features, let's create
an intranet home page and a SharePoint site for the IT
department of a fictional company, Windomain.com. You'll
see why I believe the grim
reaper is a-knockin' on your
shared folders' doors.
SharePoint Services 3.0 in a Nutshell
SharePoint Services 3.0 is a free add-on to Windows
Server 2003. If you're new
to the SharePoint family of
products, let me get you
up to speed. Once upon a time, there was Content
Management Server, which
focused on large-scale content management issues.
About the same time, Bill
Gates caught the collaboration bug and SharePoint Team
Services was born.
Microsoft's modus operandi seems to be to invest
maximum effort when a product reaches version three, and SharePoint technology
is no exception. Windows
SharePoint Services 2.0
improved on the first version but left gaping holes in
functionality and ease of use.
Content Management Server
morphed to become Microsoft
SharePoint Portal Server 2003,
which built a portal “umbrella”
over SharePoint sites. Now,
SharePoint Services and
SharePoint Portal Server have
made a significant leap: Both
were completely redesigned and are now joined at the hip.
SharePoint Services 3.0 is now
a .NET application, leveraging
all the capabilities of Microsoft .NET Framework 3.0, including workflow. And SharePoint
Portal Server 2003, renamed
Microsoft Office SharePoint
Server 2007, has become
an add-on extension to
SharePoint Services 3.0, providing not only extraordinary
functionality, which I'll examine
in an upcoming article, but
also demonstrating the robust
platform for Web-application
development delivered by
SharePoint Services 3.0.
Installing SharePoint Services 3.0
The scenario I present here
reflects a typical out-of-the-box installation of SharePoint
Services 3.0 on a Windows
2003 Service Pack 1 (SP1)
domain member server. (To
give you an effective “learn-by-doing” experience in these
few short pages, I'll leave it
to you to read the SharePoint
Services 3.0 readme file and
deployment documentation,
available from the SharePoint
Services 3.0 Web site at
http://www.microsoft.com/technet/windowsserver/sharepoint/default.mspx.)
Although Microsoft recommends you use a dual-processor server with many
gigabytes of RAM, for a small rollout of SharePoint
Services 3.0 you can get by
with less, depending on what
you're doing with SharePoint,
so don't let the published
hardware recommendations prevent you from taking
SharePoint Services 3.0 for
a test drive. In fact, I used a
1GB virtual machine (VM) to
create the prototype used in
this article. I wouldn't suggest
using such scant resources
for a production intranet, but
even a VM can provide a functional sandbox for SharePoint
Services experiments.
To install SharePoint
Services 3.0, you'll need to
have already installed .NET
Framework 3.0. Before you launch the SharePoint
Services 3.0 setup, log on to
the server using an account
that has administrative privileges. This account will be the
initial owner of the SharePoint
Central Administration site
and the default SharePoint
Services team site. You can
easily configure the account
to receive alerts related to
the health and usage of the
SharePoint Services server
farm and sites, so you might
want to use a domain user
account in the Administrators
group on the server, rather
than the local Administrator
account.
The SharePoint Services 3.0 setup will automatically
configure the Windows Internal
Database, a “lite” instance
of Microsoft SQL Server
(which is listed as SQL Server
2005 Embedded Edition in
SharePoint Services), on the
server. However, for a production rollout you'll certainly
benefit from the scalability and
manageability provided by
SQL Server, and SharePoint
Services lets you run with a
separate SQL Server installation to host the configuration
and content databases.
When the installation is
complete, run the SharePoint
Products and Technologies
Configuration Wizard from the
Administrative Tools folder on
the SharePoint server. The
wizard initializes SharePoint
Services 3.0 and creates the
first two SharePoint applications: the SharePoint Central
Administration site, and the
default content site based on
the Team Site template. You
can visit the default site at
the URL, http://servername, which Figure 1 shows. Take a
quick look, but
don't change
anything until
you've configured your
server.
Configuring the Server
Whether you install SharePoint Services 3.0 on one server or on multiple servers, you
now have a server farm. A
SharePoint server farm hosts
SharePoint Web applications.
For many implementations,
the two default applications
(Central Administration and
the default Web application)
will suffice, as the default Web
application can host an organization's hierarchy of multiple
sites. The SharePoint Central
Administration site, created by
the SharePoint Products and
Technologies Configuration
Wizard, lets you manage the
farm and the applications it
hosts. You can open the site
by using the SharePoint 3.0
Central Administration shortcut in the SharePoint Services 3.0 server's Administrative Tools folder. Make a note of
the port on which the site is
hosted (which you can change
from the site's properties by
using Microsoft IIS administrative tools). You can access
Central Administration from
any computer via a Web
browser.
The Central Administration
home page reveals a task list
of important, post-setup configuration procedures, which
Figure 2 shows. Click each
procedure to read more about
it, then mark the item as complete after you've performed
the operation. I would suggest
making it a priority
even for this simple SharePoint site
to assign a second
farm administrator
and to configure
outbound email
settings for the
server farm. You
can perform these
tasks by using
Update Farm
Administrator's
Group and
Outbound Email
Settings, respectively, at the task
list or from the
Operations tab.
You can create,
delete, and manage Web applications by using the Central Administration site's
Application Management tab.
Using the links on that tab, set
the time zone.
Within each application is
one or more site collections,
each consisting of a top-level
site and one or more child
sites. Each site contains lists,
or data tables, such as task
lists, contact lists, and document libraries. Each list contains items: records or documents, for example. If you're
unfamiliar with the structure of
a SharePoint implementation,
visit http://www.MyOfficePro.com and look for the
article “Windows SharePoint
Services, an out-of-box learning experience.” See also
the Exchange & Outlook
Administrator article, “Making
Sense of SharePoint Portal
Server Architecture,” August
2006, InstantDoc ID 93082.
In the example we're creating in this article, we'll make
our intranet home page be
the default site collection at
the root URL of our default
Web application. At the top-level site, we'll allow any user,
even anonymous users, to
have read-only access to that
site. Beneath the top-level
site, we'll create departmental subsites, readable by all
authenticated users. Users in
a department will have higher
levels of access to create and manage content based on the
functionality and resources
in their department's site.
Beneath departmental sites,
we'll have project or team
sites for secure collaboration
and document sharing. So the
URL namespace will be http://servername for the home page
(site collection and top-level
site), http://servername/department for the department, and
http://servername/department/project-or-team for collaboration.
Prev. page
[1]
2
3
next page 
