0. Introduction to Windows SharePoint Services

I have received mail saying that it would be useful if newcomers to Windows SharePoint Services (WSS) (i.e. those who have not used the predecessor product SharePoint Team Services (STS)) were to receive some background information on the product. So here it is. This is of course my own opinion and based on things I have heard as well as my own experience both with the STS and WSS products and with my acquired experience through writing the STS and now the WSS newsgroup FAQs. (The historical intro has been written based on what MS people have said in newsgroups and presentations)

The history of STS in brief is that a group inside Microsoft decided to create a portal site that would cover the main needs of a workgroup or small department (maybe the original intent was just for their department, I don't know). The software was built on the basis of (but extending) FrontPage Server Extensions because these were Office group people.

The software was implemented in one (or more?) departments and by word-of-mouth spread through Microsoft like wildfire. Previously outside consultants had been employed to create "local" web sites; these took much longer to implement; required more maintenance; and of course cost more than this new internally-made portal.

At some point this internal product was converted into a named product called SharePoint Team Services - one of those cases where it was felt that adding a product to an existing "family" was a good idea, although STS had little to do with the existing enterprise product SharePoint Portal Server (SPS).

What was the reason that the use of what was to become STS spread so quickly within Microsoft ?

-------

1. It was a ready-made site that could be implemented in hours and would run out-of-the-box on normal-sized PCs, yet could be customized and extended for the use of larger groups.

2. It contained mini versions of most of the things that a small department or workgroup would need.

3. Adding users to the site and giving them rights was simple.

Ready-made site / Extended

STS could be installed on a single server and in it's minimum version included the use of MSDE. SQL server 7.0 and SQL Server 2000 were optional database systems for the single-server version but could also be used as database systems for the dual server version (one server for the site and documents; the other for the database).

Mini Versions

In addition to the key document library and custom library functions (for storing and organizing documents), there were also Information Board(s); Discussion Board(s); and Contact List(s)

[FAQ writer's note: my sites rarely used these and concentrated on the document storage aspect - reckoning that the ability to locate documents was more important than re-creating things that could be done in Outlook]

Authentication

There were two kinds of users - domain users, who just needed to be specified to the site (or particular area of the site) and local users (who when created within STS would be created as users local to the STS server AND would be given rights to the STS web site.

Subwebs could either have the same rights as the higher-level site or could be defined as having their own users.

---------

Now what about WSS ?

One of the recommended uses for STS was for a project group.

The project would form; the project leader would ask the STS administrator to create a web site for the project and the project would post all its (external) source documents and (internal) papers to the web site. It would use the site for internal Project announcements and would perhaps (if people were located over a wide area) would use the discussion function. Nice and easy.

The main problem from the point of view of the administrator was that while creating a standard site was easy; most project groups wanted customization when they ordered the site from him/her and this customization often mean both FP UI-look changes but also changes to the standard templates. With only one set of templates per server this often caused problems - many project groups could use the same server from the server load point of view but the one set of templates per server meant that changes made for one group spread to other groups (usually when they added subwebs).

With WSS a lot of these problems disappear.

a) the project group now generates its own WSS site

[The first meeting of the project group is announced and participants are listed. On sending, the project leader is asked if he/she wants to create a WSS site for the project; if yes, the list of participants to the meeting are given rights to the site.]

b) on generation of the WSS site, a number of different templates can be selected from.

c) creation (by the administrator) of new templates is much easier than before.

(Similar things happen with a Document Workspace of course) There are of course many improvements to the user interface; to the fields that can be used in libraries and the way lists can be output; much much greater extensibility etc. etc.

But for me the key thing to remember is that WSS builds on a product that was so usable that its use spread throughout a major software company without any official encouragement to use it. WSS is just more of the same - a low cost and quick way to create web sites that are genuinely useful to their users yet need little maintenance from administrators.

Now on to the rest of the FAQ where I hope that you'll get some useful answers on how WSS works in detail.