Introduction
Today’s information workers have a constant need to collaborate, share information, and find information they are looking for. This need exists around projects and teams, meetings and documents, and furthermore on a department- and company-wide level. But also with customers, partners, and vendors as organizational boundaries more and more are disappearing. Typical approaches have been to create file shares, e-mail distribution lists, public folders on your mail server, and many more. But, these traditional approaches are difficult to manage, provide limited search capabilities, and also limited access from remote locations. The latest approach to solve such needs are enterprise portals.
Enterprise portals provide Web access to information and documents; this makes them ideal for remote access. The typical structure adopted by most enterprises is to have one enterprise-wide portal that is the default page opened when employees launch their browser. There, you find current information about the company, its strategy, and so forth. From there, you find your way to portals around departments, ongoing projects, and other topics. Most portals used nowadays are still fairly simple. More advanced portal solutions already provide search and indexing capabilities and document libraries with more advanced document management capabilities, but, most importantly, robust management tools. Organizations are constantly creating new projects and virtual teams around projects. The latest portal solutions make it very easy to create new portals, manage them, and then to discard those when no longer needed, but, most importantly, being able to search across all existing portals. Large organizations such as Microsoft, HP, GE, and so forth have hundreds of such projects and teams going on every year.
There are many portal solutions on the market; for example, from IBM, Microsoft, Plumtree, Vignette, and so on. Microsoft’s latest portal solutions are “Windows SharePoint Services” and “SharePoint Portal Server 2003.” This article will not evaluate different portal solutions but rather explain how to use and develop for “Windows SharePoint Services” and “SharePoint Portal Server 2003” from Microsoft. The first article explains the differences between these two technologies and how to install and configure each. The second article looks at how to use both from a user and administrator perspective. The last article looks at how to extend it by using its SDK and create Web parts.
The Differences Between WSS and SPS
WSS stands for “Windows SharePoint Services” and is the successor of “SharePoint Team Services.” It runs only on Windows 2003 Server (Web, Standard, Enterprise, or Datacenter Edition) and requires IIS 6.x, ASP.NET, and the .NET framework 1.1. WSS is available for free and can be downloaded from this location. Make sure that you also apply the latest Service Pack (SP1 at the time of this article). WSS can utilize SQL Server 2000 or MSDE 2000 (SQL Server 2000 Desktop Engine) as its data store.
“SharePoint Portal Server” (SPS), builds on top of “Windows SharePoint Services.” When you install SPS, it will automatically install WSS if not present. This assures that it is very easy to migrate from WSS to SPS and that any components developed for WSS can be used on SPS. It has the same system requirements as WSS: Windows 2003 Server with IIS 6.x, ASP.NET, and the .NET framework 1.1. It also can utilize SQL Server 2000 or MSDE 2000 for its data store. Also, make sure to apply the latest Service Packs for SPS, which is SP1 at the time of this article (this requires to the first install SP1 of WSS).
When to use Windows SharePoint Services
WSS is used for team and project Web sites or portals. It provides the base capabilities of creating and managing portals. You can create many top-level portals; each can have multiple sub-portals. For a smaller organization, this could be a top-level portal per department and then sub-portals for each project. For example, you could create a portal for Engineering with a sub-portal for the current and upcoming release and a portal for Professional Services with sub-portals for each ongoing customer implementation. On each portal, you can place Web parts (more later on) to show contact lists, event calendars, announcements, document libraries, and more. You can use these portals to share information within your department, projects, or meetings. WSS makes it very easy to create new portals and manage them. User rights are used to determine what a user is allowed to do. Users can be notified about events such as a document being added, a contact being changed, and the like. These notifications can be sent in real time when the event happens or via a daily or weekly summary of all events. WSS does not provide any search capabilities if it uses MSDE 2000 as its data store. When using MS SQL Server 2000, it can search within one portal, but it does not allow you to search cross many portals including sub-portals. So, you only can search for all the information within the portal you are in.
When to use SharePoint Portal Server
SPS builds on top of WSS so, by default, it provides all the capabilities WSS provides. The most compelling reasons to use SharePoint Portal Server 2003 instead of WSS is it has improved search capabilities, ability to target content to different audiences, and integration capabilities. SSP enables you to import users from Active Directory or any other LDAP data source on a one-time or scheduled basis. Audiences are used to target content to specific groups of users. When importing users from an external data source, you specify which user property is mapped to the SharePoint audience; this gives you ultimate control over how to target content, whether this is the department, location, or any other property. SSP provides a “My Site” site that is a personal portal for each user. This site provides a private and public document library, manage all alerts and links, and so forth. Any link or alert the user sets up on any portal shows on the “My Site” portal. SSP allows you to search across all existing portals; this provides a very powerful search. Through search scopes, you also can define the areas or topics that should be included in a search. The user can select the search scope when performing a search. SSP Single-Sign-On capability allows you to map portal credentials to credentials of other enterprise applications so that SSP can retrieve information from these enterprise applications without requiring an additional authentication by the user. Microsoft BizTalk Server can be used for integrations between SharePoint Portal Server and other enterprise applications. SSP also allows you to create server farms to scale over multiple servers and ultimately achieve the scale required for large organizations with thousands of portals.
Summary and where you can get a more detailed comparison
The main differentiator between WSS and SPS is that WSS is used for small teams and projects and SPS is used for company-wide portal solutions with sophisticated search and content targeting capabilities. Both can utilize MS SQL Server 2000 or MSDE 2000. Use MSDE 2000 for smaller deployments and MS SQL Server 2000 for a larger number of portals as well as corporate-wide portal solutions. The following document provides a more detailed decision guide about when to use WSS and when to use SSP. It uses typical requirements customers have and how to address them using WSS or SSP. The second article, which shows how to use SharePoint, explains the differencess of WSS and SPS in more detail.
How to Install Windows SharePoint Services
Where you can get the Windows SharePoint installation files and how to start the installation
Download WSS from this location as well as SP1 of WSS from this location. Run the executable “stsv2.exe” to start the installation of WSS. It first extracts the executable and places all the installation files in the “c:\program files\stssetup_1033” folder and then launches the installation. You can choose between the “Typical Installation” and the “Server Farm” installation. The typical installation uses the Microsoft SQL Server Desktop Engine (MSDE) that does not support any search capabilities. All portal sites you create will not provide any search box and users must manually search for the required information. The “Server Farm” option utilizes MS SQL Server, which provides a full text search. Users will see a search box that allows them to search within the portal they are in. But, it does not allow them to search across all existing portal sites (for that, you need SPS). Select the “Server Farm” option and continue the installation. This installs all the WSS files into the “c:\program files\common files\microsoft shared\web server extensions\60” folder, creates and starts a new Windows service called “SharePoint Timer Service,” and creates a new virtual server called “SharePoint Central Administration.” Note that SharePoint uses the term “virtual server” whereas IIS uses the term “Web site.” The port number used by this new virtual server is randomly chosen during the installation and can be found in the properties of the virtual server.
Launching into the WSS configuration and what to do when .NET 2.0 is installed
The install then calls “iisreset” to restart IIS and then launches a browser into the “Configure Administrative Virtual Server” page. Keep in mind that WSS uses the .NET framework 1.1. If you have already .NET 2.0 installed, you need to tell IIS which version of the framework to use, which is by default always the newest version. The install created the new virtual server “SharePoint Central Administration,” which by default uses .NET 2.0 and of course causes the WSS application not to function at all and present you with just a blank page in the launched browser. In the IIS Manager, open the properties of the newly created “SharePoint Central Administration” virtual server, choose the “ASP.NET” tab, and select version 1.1 in the “ASP.NET” drop-down list. You need to call “iisreset” again to restart the application and then refresh the blank page in the browser. This then shows you the “Configure Administrative Virtual Server” page.
How to configure the IIS application pool to use
In IIS 6.x, applications run within application pools and the WSS install creates a “StsAdminAppPool” application pool that uses the predefined identity “Network Service.” The installation, by default, uses the “StsAdminAppPool” application pool for the “SharePoint Central Administration” virtual server. The “Configure Administrative Virtual Server” page allows you to change that and select which application pool should be used when running the “SharePoint Central Administration” application. Choose an existing application pool or create a new one. In your case, you create a new application pool called “wssadmin” and type in the username and password of the Windows user used to run this application pool. The user must already exist but the application will grant it the required security rights. Make sure you enter the user name as “domain\user name” or “machine name\user name;” otherwise, you get the following error: “System Error 1057 while trying to query service SPTimer.” This performs a number of steps. It creates the new application pool “wssadmin”, uses the user credential you typed in for that application pool, assigns the “SharePoint Central Administration” virtual server to this new application pool, changes the “SharePoint Timer Service” to also use the user credentials you typed in, and assigns the user to a number of Windows groups so that it has the required permissions. The groups are “IIS_WPG” and “STS_WPG.” It then asks you to call “iisreset” again so that all the changes take effect and then to continue.
How to configure the database used by Windows SharePoint Services
Next, it allows you to choose the database server used to store WSS configuration information and the type of Active Directory integration. In the section “Configuration Database,” you enter the name of the machine that runs MS SQL Server to use, the name of the database (that will be created for you in SQL Server), and the authentication type, which is recommended to be “Windows authentication.” If required, you can type in a SQL Server user name and password. When choosing “Use windows authentication,” make sure that you have granted your “wssadmin” Windows user access to SQL Server. Open the MS SQL Server Enterprise Manager and go to the “Security” item and “Login” underneath it. Right-click on “Login” and select “New Login” from the pop-up menu. On the “Default” tab, enter “domain name\user name” or “machine name\user name” in the name text box and leave the “master” database as the default database. On the “Server Roles” tab, give the user the “Database Creators” role and click OK. The user is used by WSS to create and manage databases, so it needs these permissions at a minimum.
How to finish installing Windows SharePoint Service
In the section “Active Directory Account Integration,” you can choose whether users created in WSS have already Windows accounts. The Windows account is used to authenticate the user when accessing any of the portals. If users do not have Windows accounts yet, you can choose the “Automatically create Active Directory accounts” option and you enter the AD domain and OU (organizational unit) where the users will be created. Continue, which will create the configuration database in SQL Server and next show you the “Central Administration” page. This allows you to administer WSS and will be the page shown every time you open the “SharePoint Central Administration” application, which can be launched through the “SharePoint Central Administration” menu item added by the install to the “Administrative Tools” windows program group. Next, install SP1 by running “wss2003sp1-kb841876-fullfile-enu.exe” that you downloaded. This simply installs the latest files. Note that it does not require any restart because IIS 6.x detects a change in the files and starts a new application pool using the latest files. Afterwards, go back to the “SharePoint Central Administration” application.
