Windows SharePoint Services 3.0 Out of the Box

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.

   Previous  [1]  2  3  Next