Unlike STS 1.0 which worked on several operating systems - even if it in production tended to be installed on a Windows 2K Server variant, WSS will only work on .Net Server and in particular all versions of .Net Server except the Web Edition.

 

Jorgon Johanson of Norway send me however a lot of detail on using WSS with the Web Edition including the following.

'According to Microsoft WSS will run on the Web Edition, but there are two catches:

 

Catch 1 - The Web Edition can NOT host the database.

"You must use the remotesql=yes parameter to install Windows SharePoint Services Beta 2 on Windows Server 2003, Web Edition. For more information about installing Windows SharePoint Services Beta 2 to work with Microsoft SQL Server 2000, see Remote SQL Server Deployment."

 

Catch 2 - The Web Edition may be difficult to get hold of.

"It (The Web Edition) will only be distributed through selected partner channels and will not be available for retail. Service providers should visit the Microsoft Service Providers Web site for more information."'

SharePoint Portal Server (SPS) 1.0 and SharePoint Team Services (STS) 1.0 were two separate products that confusingly shared the same name and had limited interaction (and that, only in one direction after both Service Pack 1's came out when SPS could also include information stored in STS in its searches).

 

SPS 2.0 is built on top of WSS. As such it now adds additional functionality rather than it being a completely separate product.

Here is a list of the extra functionality in SPS 2.0 as provided in the SPS newsgroup by James Edelen

 

 

and as I didn't know what "Taxonomy" meant either, I looked it up - "classification, especially in biology" (Concise Oxford)

STS 1.0 was available on the extended Office XP (with FP) and on the FP XP CDROMs.

 

WSS is available as a free download to the Windows 2003 Server Operating System.

 

(For the link see this FAQ's "MS Articles" section via the "Useful Documents" menu item)

In STS 1.0 a common request was to have the date set to "European" i.e. DD/MM/YY or "Swedish" i.e. YY/MM/DD instead of the STS 1.0 standard US date MM/DD/YY. This and the change to a 24 hour clock were only possible outside STS at the operating system level.

 

These settings were thus valid for all the sites located on the server.

 

In WSS it is possible to set "Regional Settings" in Site Settings / Site Administration where there are selections for Locale (which presumably includes date format); Sorting order; Time Zone and Time Format (12/24 hour clock).

 

These settings are valid for *the site* which means that a single server can run sites which are operating in different time zones and with different language 'styles' (for want of a better word).

 

 

"I set Regional Settings at the site level and it had no effect on the date format in my document libraries which were contained in sub-sites. Only after I set Regional Settings in each sub-site did I get Finnish date formats."

 

In STS 1.0 the items listed in the Quick Launch section were generated from the database. They were links to (only) those lists that had been defined in the User Interface when adding or amending a list as "Yes, I want this in the Quick Launch list".

 

There was one Quick Launch list per main web or per subweb.

If you wanted to add your own links (for instance to sites outside the STS site or to pages within the STS site that were not main List pages), you had to add some (<A> </A>) HTML code just above or just below the code for the generated Quick Launch links.

 

In WSS there are several different Quick Launch sections. The initial information they contain is generated as before from the database.

 

However if you now want to add additional links (external or internal) *within* the "normal" links this is now possible through the use of Front Page 2003 by selecting first the Quick Launch section; and then either using "Add a Link" or right-clicking and adding a link after selecting 'Link Bar Properties'.

This section has been added because of the major changes made between Office XP/STS 1.0 and Office 2003 / WSS.

With STS 1.0 it was possible to import contacts from Outlook 2002. It was not possible to export contacts to Outlook 2002.

 

With WSS it is possible in an WSS Contact List to Import Contacts from Outlook 2003 and also to export Contacts to Outlook 2003.

 

In the later case, your web "area"'s (web, subweb, Meeting Place, Document Workspace etc.) Contact list will be transfered to Outlook 2003 as a new Contact Library.

 

Contacts will not be added to an existing Outlook Contact list.

 

These Contacts then appear in Outlook 2003 as an item in the "Other Contacts" section, but they may be then transfered by drag and drop into (for instance) the "My Contacts" section of the Contacts left-hand column.

 

In Outlook 2003 Contacts may (as before) be exported to a file. There is no easily accessible way to transfer the contents of a file into WSS. *as far as I can see*.

 

In STS 1.0 the Contact information available for each person was text information which could also include a URL of the person's web site.

 

In WSS the Contact information available for each person is similar if not identical (looks the same to me) to that in STS 1.0 but in addition it is now possible to add an attachment (person's photo perhaps).

 

Christian Super later commented
 

When a WSS Contact list is linked to Outlook, users generally want to use the Contact list like they do their other contact lists.  To do so, the Contact list must be made visible.

 

To add any folder containing Contact items to the Outlook Address Book:

 

1. Right-click the folder, choose Properties from the pop-up menu, and switch to the Outlook Address Book tab.

2. Check the box for Show this folder as an e-mail Address Book.

3. You can enter a new Name of the address book to make it easier to distinguish from other Contacts folders. The name change affects only the address book display, not the actual name of the folder.

4. Click OK.
 
Thanks, Christian!

With Outlook 2002 attachments could be added to mail messages. The person opening the mail message opened the version of the attached document that was available when it was attached.

 

With Outlook 2003 and WSS, the master copy of an attachment is stored on the WSS site. The person opening the mail message will always receive the latest version of the attached document.

 

This paper deals with Contacts and the interaction between WSS, Outlook, Excel and Access.

The aim of the following scenario is to ensure that the above four programs all have access to the same version of the Contacts list.

 

 

In order to export Outlook Contacts to Excel it will be necessary (the first time) to install extra functions over the "typical" Office 11 installation, so the user will need to have access to the Office 11 CDROM to perfrom this operation.

In Outlook

a. Open Contacts
b. File / Import and export / Export to a file
c. Create a file of type / Microsoft Excel
d. Select Folder to Export from / Contacts

 

In order to import from Excel into WSS it will be necessary (the first time) to install extra functions over the "typical" Office 11 installation, so the user will need to have access to the Office 11 CDROM to perfrom this operation.

In WSS

a. Click on Contacts (under Lists)
b. (from the Menu line) "Import Contacts"
c. (from Select Users to Import) Select all the contacts; Add; OK

 

** After step 2 Outlook; Excel; and WSS are in sync, but updating all of them is difficult. The next step is to create a copy of the Contacts in Access. This will become the master copy. **

 

In WSS

a. Create Linked table in Access
b. In Export - New Database

 

** At this stage all four programs (Outlook; Excel; WSS and Access are in Sync. **

 

*** From this stage on it is important that Additions to the Contacts are made only in the Access master table.***

 

 

In Access:

Add new contacts.

 

In WSS

a. Open Contacts
b. In the menu line "Refresh Data"

 

In WSS

a. Open Contacts (if not still open from 2.2.a)
b. In the menu line "Link to Contacts"

At this point Outlook (if opened and thus in the task menu bar) flashes and needs action

 

In Outlook

A query box appears with "a request has been made to add the following SharePoint Team Services folder to Outlook .....

Would you like to add it ?"

 

Pressing OK will create a new section in Outlook (Other Contacts) that contains "Team Web Site - Contacts" in addition to the standard Contacts section containing "Contacts".

 

At this point Contacts contains old information and ought in future to be ignored and WSS contacts used.

 

[Note that the same information box message appears even when "Team Web Site - Contacts" is already available.

Pressing OK will then update (=synchronize) the existing information or - if no changes have been made in Access/WSS - leave it as it was. It will not cause second "Team Web Site(2) - Contacts to be created.]

 

In WSS

a. Export and Link to Excel

 

In Excel

(Alternative 1 - Excel is open and in it your Contacts xls file
(Contacts11.xls) is open.)

b. The query box "Import Data" appears.
c. In this box select "Existing Worksheet" and as entry point a point in column A directly below the existing Contacts list.
d. OK
e. Delete the previous version of Contacts11.xls

(Alternative 2 - Excel is closed)

b. Book1.xls is created containing the new contact information.
c. Save this as Contacts11.xls thus overwriting the older version of this file.

 

** Following all these steps, you have a version of the Contacts list that is identical in WSS; Outlook; Excel and Access. **

 

*** Note that if you don't see the need for an Access copy of this information, you can follow the above scenario but omit the Access sections and do all the updating in WSS (for which I would suggest the Datasheet View). In this case, thus, WSS would be the master copy. ***

For Microsoft documents please go to

 

 

where I will try to keep them up-to-date.

 

 

 

Collutions is the company that designed the STS newsgroup FAQ in STS form(www.collutions.com/Lists/FAQ) and now also the WSS newsgroup FAQ (wss.collutions.com) on a WSS site. It is also the home site of Jim Duncan's (an STS MVP) Collutions company that provides custom solutions based on STS/WSS for web sites.

 

 

 

 

A site that I'm now told is a Microsoft site. Some useful hints of the use of FrontPage 2003 with WSS sites many of which are linked to in the MS Articles section here.

 

 

 

The WSS part of this site has lots of the same links to articles and web casts etc. that you can find here in the WSS FAQ site, but there's also extensive sections for SharePoint Portal Server 2003 and it IS organised in a different way, so you might find it suits you better.

 

 

www.sharepointcommunity.com

 

Mainly SPS 2003 but also includes WSS links.

 

 

 

This is Dustin Miller's company's site. It's a consulting and development firm which also has some STS add-ons. These days also a training firm that provides at its "Boot Camps" in-depth training in WSS. They also have a web hosting service (see below VII.3) and a undelete product for WSS.

 

 

 

This is a source of STS/WSS information. It's also linked to perhaps the oldest specialist STS/WSS web hosting company - UnifiedWebMedia (see below VII.3). These days sharepointtips.com mainly links directly to the wss.collutions.com information.

 

 

 

Run by Gokcen Karan (writer of a book on WSS [in Turkish] that will be out in June 2005), this is a site for Turkish SharePoint Users and Developers.

 

 

 

This is an online community, run by SharePointExperts (see above), for STS/WSS users and developers. There are code samples, how-tos, SharePoint-related news and a very active online discussion forum.

 

Some areas require free registration, others such as the link to "Other SharePoint related sites" (where you'll find this FAQ in PDF form) do not.

 

 

 

This is the site that hosts the SharePoint Portal Server FAQ. Originally, naturally, for version 1 of that product, it now also covers version 2.

 

Useful for those people who are considering "upgrading" WSS to SPS and also for those people who just love to add code to their WSS site.

 

 

 

Their own set of questions and answers ...

 

(SPS 2003 is at appid=4 in case you need that too)

 

 

http://www.wssdemo.com/ 

 

Here's a brief explanation of what this site is about (quoted from the site in extract)

 

"This site is not a true WSS FAQ, there are plenty of other sites providing that" ....

 

"I enjoy doing cool things with WSS and FrontPage. Some examples of this can be seen on this site." ...

 

"I will endeavour to write some articles that explain how to achieve these effects using FrontPage 2003 (and Windows SharePoint Services, XML Web Services, XSLT Data Views)."

 

 

 

 

 

or

 

 

 

(Courtesy of Jorgon Johanson of Norway and only edited in a minor way)

One of the great new features of WSS seems to be how easy it is to use Site and List templates. Templates can be used to generate "pre-cooked" site and list setups that can be applied when generating new sites, lists and document libraries. Site templates includes the the look (theme), the layout of the home page, the lists and document libaries and so on. List templates include the views, pre-generated columns and so on.

Since both Site and List templates can optionally also be generated *with* contents, templates are a convenient way of moving both sites and lists (see below).

Making a Site Template

Browse to a site that is to be used as a source for the template. Then go to:

Site Settings
Go to Site Administration
Management and Statistics: Save site as template

Decide on a file name (the xxxxxx.fwp file). Decide on a template title and a description for this template. Also, decide if the *contents* (of all lists and document libraries) should be included in the template. If you are going to use the template for migration purposes, check "Include content". Also, if you want to create new sites complete with some contents, check "Include content". Otherwise you may leave "Include contents" unchecked. Click OK.

Note that possible sub-sites of the site used as a source for a template will NOT be included in the template (this option is currently missing in WSS).

The new Site template will now show up in "Site Collection Catalogs: Manage site template catalog" in the root site (see "Managing Templates" below). Note however that the new template will be available for use in the top level (root) site and all sub-sites.

Generating a New Site From a Template

There are many places where you are given the possibility to generate a new site. The new site can be based on one of the predefined templates or on one that you have created yourself. First browse to the site that is to be the parent site. If this is a sub-level site, you have the following possibilities:

Create
Web Pages: Sites and Workspaces
- or -
Documents and Lists
See Also: Sites
Create
- or -
Site Settings
Manage sites and workspaces
Create

If you are going to create a site just below the top level site you have the additional possibility:

Site Settings
Go to Site Administration
Manage sites and workspaces
Create

Either way, give your new site a Title, a short Description and also it's URL name (which unlike STS 1.0 can be different to the Title name). Hit Create and you will be given the oppertunity to select a template. If you have generated any Site Templates yourself you will see them in the list. Select one and hit OK.

Making a List Template

Browse to the list or document library that is to be used as the source for the template. Then go to:

Modify settings and columns
General Settings: Save list as template
Decide on a file name (the xxxxxx.fwp file). Decide on a template title and a description for this template. Also, decide if the *contents* (text etc. in lists lists or the actual documents of document libraries). If you are going to use the template for migration purposes, check "Include content". Also, if you want to create new lists/libraries complete with some contents, check "Include content". Otherwise you can leave "Include contents" unchecked. Click OK.

The new List template will now show up in "Site Collection Catalogs: Manage list template catalog" in the root site (see "Managing Templates" below). Note however that the new template will be available for use in the top level (root) site and all sub-sites.

Generating a New List From a Template

The new list template will be available from the Create Page. It shows up under Document Libraries, Picture Libraries, Lists and so on according to the type of the list used to create the template.

Managing Templates

You can admininister your Site and List templates by going to these locations on a *main* (root, top level) site:

- Site Templates:
Site Settings
Go to Site Administration
Site Collection Catalogs: Manage site template catalog
- List Templates:
Site Settings
Go to Site Administration
Site Collection Catalogs: Manage list template catalog

The two catalogs are actually two special purpose document libaries. The "documents" held in the libraries are template files (xxxxx.fwp files).

Migrating Sites and Lists

Since the Site and List templates are stored in .fwp files moved into the two special purpose documents libraries (the Site Template Catalog and the List Template Catalog), it is easy to get the template out of the current site by just clicking on one of the templates and save it to some location (locally). It is then just as easy to Upload the template to another WSS site by clicking "Upload Template" in the appropriate Template Catalog (don't confuse Site templates and List templates).

Since a template can be generated with the total contents of a site or list, this feature can be used to move whole sites and lists. Note however that a Site template does not include the sub-sites of the original site. This means that when moving a site tree you will have to move one (sub)site (the root or one of the branches) at a time.

STS 1.0 had certain functions (such as Open Document) that relied on the presence of Office XP in the client workstation.

 

However most functionality was available to Office 2K (and Office 97?) users.

 

Users of Office who didn't have STS 1.0 installed had full Office functionality available.

 

With WSS some administrator functions are only available to users with FrontPage 2003 installed on their clients. (For instance it's essential for some site amendments)

 

Users of Office 2003 get full functionality only if they have WSS installed.

 

One part of full functionality is the opening up in for instance Excel of a WSS Document Workspace where documents from selected WSS document libraries are listed; can be amended and additional documents can be uploaded to them from within Excel.

 

Note: See also section V where this Office / WSS relationship is dealt with in detail

Just as FrontPage XP could be used for a certain amount of basic customization with STS 1.0, so FrontPage 2003 can be used for similar customization with WSS.

 

Front Page 2003 also extends (compared to STS) the range of customizations that are possible.

 

The use of back versions of FP is not possible in connection with a WSS site.

 

In STS 1.0 it was dangerous to amend certain of the template and similar files with FP. It is unknown whether this is the case with WSS.

 

 

Modifications to the Default.aspx file with Frontpage will prevent 'Ghosting' from working for that site or subsite.

 

STS 1.0 used as default MSDE 1.0 and also worked with both SQL Server 7.0 and 2K.

 

WSS uses as default WMSDE which is a special version of MSDE 2K and ONLY works with SQL Server 2K (and variants) not 7.0.

 

Note that in order for SQL Server 2K to work on a Windows 2003 Server it (SQL Server) must use Service Pack 3 or later. (Ed: in fact SP3a)

 

Note also that some functionality (see below I.7) is not available with MSDE 2K.

 

 

 

 

Finally, note (SPS v2 only) that if you are installing onto a Domain Controller, MSDE is not available as an option.

STS 1.0 stored documents in the File system while the database contained information on the location of the documents.

 

WSS stores documents in the database.

In STS 1.0 the search function (as provided by MS) searched only in documents.

 

In WSS the built-in search function now searches on the contents of both documents and lists.

 

In STS 1.0 the search function was always available no matter what database was used.

 

In WSS the search function is no longer available for sites with MSDE 2K unless they also have SPS 2.0 (SharePoint Portal Server 2.0) installed.

 

(The options are SQL Server searching or SPS 2.0 searching. SPS 2.0 searching works where the WSS database is either SQL Server 2K or MSDE 2K; SQL Server searching works only where the WSS database is SQL Server 2K. MS recommend SPS 2.0 searching for very large sites)

 

In STS 1.0 adding file types to the indexing routines required very difficult adjustments. The only company which provided a routine for this was Adobe who provided a routine that both added an icon for .pdf files (as IV.2) and added .pdf files to the types covered by the search. Otherwise the only option was to allow indexing of *all* file types. (Recently a Visio filter - untested by this user - has become available from Microsoft for searching Visio files).

 

In WSS indexing is SQL Searching or SPS Searching (see I.7.1).

 

 

In STS 1.0 Virtual Servers could either be created by specifying a new TCP-IP address or by the use of (Front Page) host headers.

 

In STS 1.0 all Virtual sites retained the look and feel etc. of the main site as defined in the single set of templates for that STS installation.

 

In WSS it is easier to define Virtual Servers. It is also possible for each virtual site to have several main WSS sites (and naturally below them several subwebs).

 

In WSS a Virtual site can be configured differently to the main site (and to other Virtual Sites).

STS 1.0 had "version control". It wasn't. It simply meant a *very basic* read-only function that most site administrators turned off. In order to have true versioning of documents, administrators needed to buy and install Visual Source Safe (which worked well with STS 1.0)

 

WSS now does have true version control - that is both versioning and check-out/check-in.

STS 1.0 had very basic Help files provided by Microsoft.

 

WSS allows the administrator (and others, if he/she so desires) to both amend the existing help files and add new ones (see *).

 

Unlike the help file supplied with beta-1 which was just as basic as that provided with STS 1.0, the WSS RTM help file contains some good text (some of which seems to have been borrowed from early versions of this FAQ!).

 

* The existing help files are Copyrighted by Microsoft.

 

Initial feedback from Microsoft during the Beta process was that it is likely that additional links (to own help files) may be allowed from the main Microsoft help page but that no other changes may be made to the Microsoft-provided help files.

 

If taken to this extreme, this would greatly reduce the additional functionality of allowing users to amend and add their own help files.

 

However as yet, no change in this restrictive policy has been indicated by Microsoft.

On an STS 1.0 Server only one language was possible (one per server).

 

On an WSS Server several languages are possible (one per main site).

 

STS 1.0 was available for the same languages as WSS see below (minus Hindi ? - the list produced in August 6 2001 does not include Hindi) with the same languages being fully translated.

 

WSS is available for the following languages

 

- fully translated (="Localized")

Arabic; Czech; Danish; Dutch; English (British, US); Chinese (HK, Simple, Traditional); Finnish; French; German; Greek; Hebrew; Hungarian; Italian; Japanese; Korean; Norwegian; Polish; Portuguese (Brazilian, Portugal); Russian; Spanish; Swedish; Thai; Turkish

 

- not translated but local language(s) may be used (="Enabled"):

Bulgarian; Croatian; Estonian; Hindi (with Indic); Latvian; Lithuanian; Romanian; Serbian; Slovak; Slovenian; Ukrainian

 

 

["Enabled" has been described as follows - "When a site is enabled, the UI is in English. Anywhere a user can enter text in the interface of a WSS site will allow the user to input the enabled language." Or, I suppose, you can use the alphabet of your language.]

See
 
I.12.1 Content
 
I.12.2.1 Alerts - Subscribing to
 
I.12.2.2 Alerts - Amending the text

 

and
 
I.12.3 File Types you can't upload

In STS 1.0, a Document Library consisted of one (folder-)level of documents. The appearance of sub-folders was simulated by the use of Views where the types of documents were divided up into groups on the basis of the contents of one or more (custom) fields.

In WSS, Views are still available just as in STS 1.0, but in addition it is now possible to also have sub-folders of a document library. The document library maintainer can thus use either or both techniques whichever is more suitable for the particular type of documents.

(A two-level off-line copy of a web site for instance would be very suited to the sub-folder technique for instance. A set of documents from different sources would perhaps suit more the View approach)

In WSS Views also incorporate new options such as

Group By
Totals
Styles
Folders

In particular Group By could be used as a further way of simulating sub-folders.

In STS 1.0 it was possible for a user to subscribe to a document library so that he/she would be notified whenever a change was made to the document library.

 

In WSS it is possible to subscribe to documents and thus receive notifications at document level.

 

In STS 1.0 you could upload to a document library any file you liked. This obviously had the drawback that you could upload a script (say) and by clicking on it start it carrying out its functions. The usual way round this was for the Administrator to request that such "dangerous" file types (scripts, exes etc.) should be zipped and then the zip file uploaded to the document library.

 

In WSS there is a set (long) list of file types that can not be uploaded to a document library.

 

This file () can of course be amended by the administrator - usually I suspect to reduce the list of restricted file types rather than to increase the number. As I wrote enough the default list is *very* long.

 

The file is ....60/CONFIG/DOCEXTFL.XML

 

To change the list of non-uploadable files you can either amend the file itself (and probably do IISRestart to make it work) or you can use the User Interface *on the server* as follows (the example being removing chm files from the list).

 

1. Programs

2. Administrative Tools

3. Open SharePoint Central Administration
4. Under Security Configuration, click Manage blocked file types
5. Remove the line for CHM and click OK

 

See

 

I.13.1 Lists - Content

 

I.13.2  Lists - Attachments

 

I.13.3  Lists - Limits in the number of fields per list

 

I.13.4 Lists - Limits in the size of fields per list

 

and

 

I.13.5 Lists - What graphics formats are supported for Thumbnail creation in a Picture Library?

In STS 1.0, the List consisted of the data you entered into it.

 

This data could not be formatted per item but only per List. (i.e. you could specify for all the items in the list that the field XXX should be 'Ariel Bold 14 Red', but you couldn't specify that a particular item should contain somewhere 'Ariel Bold 14 Red' text).

 

In WSS, the data entered for a particular item can be formatted (even individual words or groups of words).

Note: This only works for Lists but not for Document Libraries and also only works there for Multi-line fields.

In STS 1.0 no attachments were possible. The nearest you could come to this was to move a document to a document library and - having created a new Hyperlink field for the list - add a link to this document.

 

In WSS attachments to an item in a List are supported.

 

 

Limits on the number of fields in a list in STS 1.0 are unknown to this author.

 

The limits in WSS for lists are as follows

 

There is a maximum of 64 text fields per list. Text fields are fields of the following types

 

"single line of text"
"Choice"
"Hyperlink" (each takes up 2 text fields in the database)
"Picture" (each takes up 2 text fields in the database)

 

Note that Multiline Text fields are not text fields in the above sense.

 

Other limits per field type per list are as follows

 

(note that similarly to text fields, number-type fields (Number and Currency) are restricted to 32 *in total* per list)

 

Multiline text fields - 32

Number or Currency Fields - 32
Date/Time Fields - 16
Lookup Fields - 16
Yes/No Fields - 16
Calculated Fields - 8

 

The number of fields possible for Document Libraries are slightly different because of the pre-defined fields for a standard document library (in brackets below). Removing these pre-definded fields from the above figures give the following limits

 

Text Fields - 57 (5)

Multiline text fields - 31 (1)

Number or Currency Fields - 32
Date/Time Fields - 16
Lookup Fields - 16
Yes/No Fields - 16
Calculated Fields - 8

 

(Information courtesy of Jerry Orman - text by the FAQ writer)

 

A single-line field is by default 255 characters in length.

 

A multi-line field is **in a document (or forms or or picture) library** by default 255 characters in length.

 

A multi-line field in **any other list type** has no such limit (one correspondent had over 5000 characters in such a field).

 

 

 

Zlatar Hrvoje adds the information that

 

 

 

Thanks Zlatar (or should that be - Thanks Hrvoje?)

Roger Williams adds
 
Apparently CAML allows this with the MaxLength= attribute. I as able to define one of 500 characters. But OWS.JS (in the UI) has the 255 character limit hard-coded inside.
 

Thanks, Roger!
 

See

 

I.14.1 Supported Browsers - General Information

 

and

 

I.14.2 Supported Browsers - Web Parts

In STS 1.0 there were problems accessing STS sites from Macs and by users using Netscape browsers.

 

I'm vague on the details but I seem to remember that in addition to the need to use Basic Authentication there was also some loss of features (i.e. some things didn't work). In addition some older versions of IE didn't work entirely satisfactorily.

 

In WSS I've been told that (and this is a direct quote from inside MS - with my thanks to the sender)

 

"Any Windows, Macintosh®, or UNIX client can use Windows SharePoint Services ... features, providing the client runs the following software:

 

 

Microsoft Internet Explorer 5.2 or later for Macintosh,

 

or Netscape Navigator version 6.2 or later

 

So we're including Mac and Unix running IE 5.01 or later and NS 6.2 or later."

 

 

 

 

 

 

 

 

 

According to a seminar given by MS on Web Parts, the full Web Part experience is available to users of IE 6.0 and 5.5 and Netscape 6 and 7 only.

There is a useful table on the Microsoft site here

 

 

("About Web browser support for Web Part Pages")

 

According to it even Netscape 6 (and 7?) users on Windows are second-class citizens.

In STS 1.0 a common request was to have the ability to amend error and other systems messages such as the message informing someone that they an amendment has been made. Usually in STS 1.0 the answer was that such messages were hard-coded and could not be changed.

 

In WSS Error messages are still hard-coded. Most of them are stored in the fpext.msg file which is not editable.

 

(space left for system messages info)

In STS 1.0 all users, irrespective of their STS roles (Browser, Author etc.), saw the same web pages.

 

This meant that even Browser users were allowed to see Site Settings and change parameters BUT were then not allowed to save their changes because of incorrect authorization levels. This led to confusion and help requests to the administrator.

 

One workaround used was to hide the link to Site Settings behind a graphic image on the page on the assumption that only people who knew this link was there would bother to click on the graphic image and if anyone without rights did so by chance - Tough!

 

In WSS all users irrespective of their WSS roles still see the same web pages with all the above consequences and workaround possibilities.

 

Note that there is one exception to this rule. A user can – in addition to the standard pages - also see *their own* pages through specifying “Personal View”.

 

In a *Portal Server* installation you can create "audiences" and then you can target portal site content for viewing by one or more specific audiences. (The default audience being 'all portal users'). However this will apply only to the Portal Server part of the site and not to any WSS sites created in a Portal Server system.

In STS 1.0 Web Parts could not be used. Their use was restricted to SharePoint Portal Server (SPS) 1.0 only

 

In WSS Web Parts are an integral part of the product.

 

In STS 1.0 there were five default Roles - Browser, Contributor, Author, Advanced Author and Administrator.

 

These were predefined rights from the same list of total rights for the site and by default as you moved up the scale you had the same rights plus more.

 

This list was divided into three main categories - Web Design Rights; Team Contributor Rights and Web Administration Rights.

 

By default no user except the Administrator had rights to any of the options in the Web Administration Rights section and to those parts of the "Web Design Rights" section that were indeed Web Design Rights.

 

There was also very little difference between a Browser; and Author and an Advanced Author (again by default) with an Author in addition to the functions available to a Browser being able to create/update/delete HTML pages and directories; and the Advanced Author on top of that being able to "Design Lists" (Create and customize lists).

 

In WSS there is a much clearer set of main categories and greater differences between the different standard roles.

 

There are still five categories of default roles but these have changed in character.

 

- The Guest role has no equivalent in STS. Users with this role can only read *specific* lists and documents when specially given permission to do so.

 

- The Reader role is equivalent to the former Browser role and can only view items; document; discussion comments and pages in a Web Site (although strangely can also Create a Web Site using Self-Service Site Creation).

 

- The Contributor Role is roughly equivalent to the former Author role (but has also rights to amend the users own Personal View [this function was not available in STS at all].

 

- The Web Designer Role lies between that of the STS Advanced Author role and the STS Administrator role with a greatly extended ability to amend the content of a web site.

 

- The Administrator Role as before has full control of the site (all selections are specified)

 

In addition to the change of roles there are now clearer definitions of individual rights. For instance in STS one selection was Create/Edit/Update HTML Pages. This is now three different selections Add; Edit; Delete. Similarly in STS there was one selection for Create/Rename/Remove a subweb. This is now two different selections (Create and Manage). There are now two different selections for the right to a) apply a theme or borders and b) apply a style sheet.

 

In addition the division of the list into List Rights; Site Rights; and Personal Rights is much clearer than the STS divisions (see above).

The Administration Guide recommends the use of SQL Server rather than MSDE if you are supporting more than 10 “active and large Web sites”.

 

For more than 1,000 sites, the same source suggests installing SQL Server on a separate server.

 

[The next level would be a couple of Web Servers and a Couple of SQL Servers. The Admin Guide does not indicate at which point such a configuration would be necessary.]

 

Neither of the following are visible and available for use

 

- multiple file upload

- datasheet view

 

None of the new interactions with Office products such as

 

- Creation of Meeting Workplaces in connection with an Outlook Calendar "Create Meeting" action

 

- Creation of Document Workspaces when saving a document in Word/Excel

 

- Saving of an Outlook attachment in WSS so that for instance people opening the attachment after a change has been made to it see the new version

 

- Synchronization (see section VI for more details of this)

 

Andrew Couch also gave me this information -

 

 

John Miller added that

 

Presence context menus are available with Office XP if you have Windows messenger installed (Not .NET Messenger)
 

 

 

See the "MS Articles" section in this FAQ for the current link to that.

 

 

Windows 2003 Server only runs under VMWare Workstation 3 if USB is disabled.

 

Note that this is not officially supported

 

Windows 2003 Server also runs under VM Workstation 4,  on which platform people have also had WSS (as part of SPS 2.0) running successfully.

 

(Thanks to David McKenzie for the Workstation 3 update)

 

Oisin Grehan reminds me that it also runs fine under VM Workstation v 5

 

(I have been running this myself since it came out).

 

Licensing is as always something that should be checked with Microsoft.

 

As usual each part of the puzzle needs to be licensed seperately.

 

So

 

a) standard licensing for Windows 2003 Server (and upwards)

 

b) standard licensing for SQL Server (if this is used) and *presumably* free use of MSDE if this is used.

 

c) WSS supplied as a free download.

 

Again, these are a best guess only. To be sure, ask Microsoft.

 

 

 

The answer is that in this case there is a Windows Extranet Connector license and that will cover Windows SharePoint Services

 

(http://www.microsoft.com/windowsserver2003/howtobuy/licensing/extconnector.mspx)

 

since Windows SharePoint Services is part of the Windows CAL

 

(http://www.microsoft.com/windowsserver2003/howtobuy/licensing/sharepoint.mspx)

 

The Windows Server External Connector license is $2,000 per server.

 

STS 1.0

 

a. If no database system was installed on the STS server - MSDE 1.0 was installed.

 

b. If SQL Server (7.0 or 2K) was installed on the STS server prior to installing STS 1.0 - no new database system was installed and the STS databases were created in the existing db system.

 

c. If the user wanted to use a database on a remote server he/she used the /nd parameter on installation and no database was created or used on the STS 1.0 server.

 

WSS

 

a. If no database system is installed on the WSS server - MSDE 2K is installed. (Unless your server is a Domain Controller in which case this is not an option)

 

b. If SQL Server 2K is installed on the WSS server prior to installing WSS - a second instance of "SQL" is installed for the WSS databases. This "second instance of SQL" is in fact MSDE 2K not SQL Server 2K.

 

If the user wants the existing SQL Server 2K to be used for WSS he/she needs to follow the procedures for SQL Server on a remote server (c).

 

c. If the user wants to use a database on a remote server he/she must install from the command line and use the remotesql=yes parameter and no database is created or used on the WSS server.

In STS 1.0 there were four main sets of files

 

a. Templates - on the same drive as the operating system

It should be noted that only the standard templates are stored here. Information on all amendments to these standard templates are stored in the database.

 

b. IIS Metabase - %SYSTEMROOT%\SYSTEM32\INETSRV\Metabase.bin

c. Documents - default: under InetPub\wwwroot otherwise where specified in the file system

d. Databases - located where you specified on installing the database

 

In WSS there are three main sets of files

 

a. Templates - on the same drive as the operating system in a *similar* location to STS 1.0

b. IIS Metabase - %SYSTEMROOT%\SYSTEM32\INETSRV\ (containing MBSchema.xml; Metabase.xml; MBSchema.bin.00000000h; and (for the benefit of older programs that look for it) a dummy file called Metabase.bin)

[History files are stored at %SYSTEMROOT%\SYSTEM32\INETSRV\History]

 

c. Databases (include documents) - located where you specified the databases would be when you installed the database

 

 

 

a. The Main Site

 

located at http://<servername>;

 

b. Document Libraries created in the main site

 

located at http://<servername>/<doclibname>;

 

c. Subwebs to the mainsite

 

located at http://<servername>/<subwebname>;

 

d. Document Workspaces created while in the main site

 

located at http://<servername>/<docworkspacename>;

 

(Document Workspaces created while in a subweb to a main site are located at http://<servername>/<subwebname>/<docworkspacename>)

 

e. Meeting Workspaces created while in the main site

 

located at http://<servername>/meetings/Meeting1; http://<servername>/meetings/Meeting2 etc.

 

Note: From the above URLs you can see that from the URL alone it is impossible to tell whether you are looking at a Document Library; a Subweb or a Document Workspace. Meeting Workspaces however have their own page with a list of all Meeting Places - namely http://<servername>/meetings

 

Note 2: The total list of the above Subwebs; Document Workspaces; and whether or not there are any Meeting Places can be obtained by going within the Main Site to "Site Settings" followed by "Manage Subwebs". In order to obtain the full list of Meeting Workspaces you need to click on http://<servername>/meetings in the list. This item is not present in the list of "Subwebs" if no Meeting Workspaces have been created. Note that this "total list" does not include Document Libraries.

 

An alternative method to get all the above (but still no Document Libraries) listed is to go to Site Settings / Site Administration and in the Site Collection Administration section access 'View Subweb List'. In this case all the meeting places are listed as well as the Subwebs; and Document Workspaces.

 

This listing also includes the listing of document workspaces within subwebs.

 

One way to get a list of Document Libraries is to go to 'Site Settings' and within the Customization section, access "Modify Site Content". This gives a list of all Lists and Document Libraries. Another way is to select "Document and Lists" in the menu line.

 

Lower-level sites can be listed in various ways (Thanks to Jorgon Johanson for this)

 

Site Settings
Go to Site Administration
Management and Statistics: Manage sites and workspaces
- or -
Site Settings
Go to Site Administration
Site Collection Administration: View site hierarchy

 

They can also be listed in several places in SharePoint Central Administration.

 

Useful Tip: Because the URL is (as above) non-indicative of whether the 'site' in question is a subweb / meeting place / document workspace etc., it is even more important than before to use a good name in the Title - this "Subweb Title" is listed alongside the URL name when "Manage Subwebs" is selected.

 

f. Lower-level sites

 

these are located at

 

http://<servername>/sites/<lowerlevelsite>;

 

g. Document Libraries created in the lower-level site

 

located at

 

http://<servername>/sites/<lowerlevelsite1>/<doclibname>;

 

h. Subwebs to the lower-level site

 

located at

 

http://<servername>/sites/<lowerlevelsite>/<subwebname>;

 

i. Document Workspaces created while in the lower-level site

 

located at

 

http://<servername>/sites/<lowerlevelsite>/<docworkspacename>;

 

(Document Workspaces created while in a subweb to a main site are located at

 

j. Meeting Workspaces created while in the level site

 

located at

 

http://<servername>/sites/<lowerlevelsite>/meetings/Meeting1;
http://<servername>/sites/<lowerlevelsite>/meetings/Meeting2 etc.

 

The same notes apply to lower lever sites as to the main site

 

(With the exception of the possibility of listing from the Site Collection Administration section because this applies only to the Main Site).

The Define Managed Paths feature is targeted at this kind of scenario.

 

You use Define Managed Paths to exclude the URLs of the existing application(s) from being processed by the WSS ISAPI filter.

 

The definition can be changed in the section of WSS where you specify Virtual Server settings.

 

 

 

Note: This section is here purely because the compiler had trouble finding how to do this. It is of course the same as how to access any Windows 2003 Server from XP Pro. Handling possible Security Problems caused by doing this this way are up to the reader.

 

Windows 2003 Server comes with 'Remote Desktop for Administration' switched off.

 

Switch it on with (on the server with Administration Rights)

 

Start
Control Panel
System
Remote
Click the box marked 'Allow Users to connect remotely to your computer'
OK

 

Then if you haven't already done so, you have to set up XP Pro to be able to make a 'Remote Desktop Connection'.

 

(On the workstation)

 

Start
All Programs
Accessories
Communications
Remote Desktop Connection
Select Options
write in name of server (works best for me)
etc.

Before you install WSS you should check two things

a. That in IIS the "Run WWW Service in IIS 5.0 isolation mode" check box is cleared.

 

b. That FrontPage 2000 Server Extensions are not running on the virtual server at port 80.

Note: b. would happen by default if the server had been upgraded from Windows 2000 to Windows 2003.

See

 

II.10.1 Can I install WSS to a domain controller?

 

and

 

II.10.2 Why should I perhaps not install WSS to a domain controller?

Yes.

 

It's unclear as to whether this is a recommended method or not.

 

Certainly Microsoft have stated that WSS will be able to install (it's version of) MSDE on a domian controller and that this is in fact the way Small Business Server 2003 will ship with WSS configured.

 

In any case there is one clear rule to follow. Always install IIS after the server has been promoted to a Domain Controller role. (Otherwise following installation there will be authentication problems).

 

1. Because Active Directory Account Creation mode is not supported.

 

2. (SPS v2 only) Because the option of using MSDE as your database is no longer available.

 

 

 

 

see "I.16 Do I see Different views of the information for different users?" (Both STS 1.0 and WSS show identical web pages to users irrespective of their roles.)

 

There seems to be much more granularity (options) when defining the rights of normal users.

STS 1.0 had the "Server Health" function which was intended to make sure that the data on the file system and the data in the STS database were in sync.

 

WSS uses the WSS database for all the data that was previously located in two locations and thus there is no longer a need for the "Server Health" function in WSS.

STS 1.0 had logging to C:\WINNT\system32\LogFiles\W3SVC1 (and W3SVC2, W3SVC3 etc.)

 

WSS has (RTM) a configurable registry key that you can set to control how verbose the logging is.

 

Critical events will be logged to the application log in the event viewer.

 

The stsadm.exe command line utility uses a log file called stsadm.log which is stored in the temp directory of the person running this utility.

 

The log for the w3wp process (w3wp.log) is stored in the windows temp directory.

 

Location to change the LogLevel

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\6.0

Change the LogLevel to Value Data of 9

The Loglevel is by default set to 0.

 

(If you look in this container you also find the key MaxLogSizeKB. I assume this specifies the maximum log file size, don't know what happens if this size is reached.)

 

More logging is available after setting this registry key

 

 

See

 

III.5.1 Relation to directory names

 

and

 

III.5.2 Forbidden characters

 

and

 

III.5.3 How can I change a site name?

In STS 1.0 the name of a subweb was automatically the physical name of the directory. The same applied to document libraries.

 

In WSS you need to specify both the subweb / doc lib name and its "physical" name separately. They may still be the same but don't have to be.

In WSS Site Names may not contain the following characters.

\ / : * ? " < > | # { } % & <TAB>"

 

In addition site names may not begin with underscore "_" as this is reserved.

 

Finally, here is the WSS invalid character set (which I would guess means for the names of files that you upload to WSS)

 

" # % & * : < > ? \ { | } ~ 

Note too the following limits on the number of characters used for file names etc.

 

 

File and folder names cannot be longer than 128 characters.

 

Also note that the complete URL for the file or folder cannot be longer than 260 characters.

In addition Megan points out that a file name cannot contain 2 periods in a row.

Thanks, Megan!

 

"Dread Pirate" points out that there is now a KB article with a similar (longer?) list of these characters here

 

http://support.microsoft.com/default.aspx?scid=kb;en-us;905231

 

(Thanks to him/her)

(This answer is specifically for SPS 2.0 but should also apply for a WSS installation with different addresses - i.e. http://server and http://server/subsite)

Site collections like http://server/sites/teamsite cannot be renamed.

Subsites like http://server/sites/teamsite/subsite can be renamed by opening the site in FrontPage by going to Tools,

Site Settings and changing the Web Name:.

Where the site is a site collection, you have a couple of options

1. Create a new site with a new name but do not apply a template and use smigrate.exe to migrate the original site to the new site. This option does not preserve security.

2. Use stsadm.exe -o backup/restore to backup the site and restore it to a new name. After restoring you can delete the original site. This option is full fidelity and does preserve security.

 

Cornelius J. van Dyck had this detail

 

The best way I've found to achieve your server rename, for which you will require another SQL server, is as follows:

 

1.  Shut down your WSS installation by terminating all connection to it and
shutting down IIS.  This will prevent any unexpected connections during the
process.
2.  In SQL Server, detach from the WSS databases.
3.  Copy the database files to the "spare" SQL server.
4.  Attach the database files on the "spare" SQL server.
5.  Ensure your SharePoint user account has propper access rights to the
newly attached database.
6.  Start "SharePoint Central Admin" from "Administrative Tools".
7.  Click "Set configuration database server" in the "Server Configuration"
section.
8.  Change the "Database server" field to that of the "spare" SQL server.
9.  Click the "OK" button.
10.  Click "Set default content database server" in the "Server
Configuration" section.
11.  Change the "Database server" field to that of the "spare" SQL server.
12.  Click the "OK" button.  Your server is not running off the remote
database.
13.  Rename your server.
14.  Start "SharePoint Central Admin" from "Administrative Tools".
15.  Click "Set configuration database server" in the "Server Configuration"
section.
16.  Change the "Database server" field to that of the new server name.
17.  Click the "OK" button.
18.  Click "Set default content database server" in the "Server
Configuration" section.
19.  Change the "Database server" field to that of the new server name.
20.  Click the "OK" button.

 

 

Sebastian Seidel had a possible other way.
 
I use the stsadm-Tool.

 

"stsadm.exe -o renameweb -url http://myserver/mysite -newname mynewsite"