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)

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.

 

 

 

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).

 

Yes. The compiler of this FAQ has had good experiences with Windows 2003 Server running Microsoft Virtual Server (pre-release=acquired version) and WSS with several XPPro clients within MS Virtual Server able to access the WSS system via IE 6.0.

 

This worked satisfactorily on a PC with 256 MB of main memory and one P IV 1,5 processor (the memory only allowed one XP Pro session to be open at a time). It also worked - but not satisfactorily - on a portable with 256MB of main memory and a PIII 800MHz processor.

 

(It now works much better on a PIV 2,5M notebook with 1 GB of memory - but does that surprise anyone ?)

 

 

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.

 

 

 

 

The default value for the "Upload Limit", which is what controls the total size of documents you can upload at one time, is set to a (in my opinion) far too low 50MB.

 

In order to increase the size do the following.

 

On the Server (under Administrative Tools) click on

 

"SharePoint Central Administration"

 

"Configure Virtual Server Settings"

 

"Default Site"

 

"Virtual Server Default Settings"

 

"Maximum Upload Size"

 

Specify a larger figure than the standard 50. I use 300.

 

----------------

Another possibility is that you have specified quotas that would be exceeded by the transfer.

 

To amend the existing quota values do the following

 

On the Server (under Administrative Tools) click on "SharePoint Central Administration"

 

In the Section "Component Configuration" click on "Manage Quotas and Locks"

 

(Thanks to Emmanuel Bouvier for the suggestion to add this alternative problem)

WSS has problems when adding large documents.

 

Problems seem to start at a document size of > 70MB and with documents over 100MB almost always being rejected.

 

(Note: this is partially corrected with SP1)

There is limit in the size of a WSS site that can be packaged with FP 2003.

 

This limit is ca 125MB.

 

 

You can enable session state by uncommenting the following line in the web.config

 

<!--
<add name="Session" type="System.Web.SessionState.SessionStateModule"/>
-->

 

In addition you need to set the <pages> enableSessionState attribute to true.

 

 

 

 

 

(Note: probably because the above [Stephane] paragraph was only in www.wssfaq.com)

 

He does however add two things that may help you all

 

- the line specified above is in the <httpModules> section

 

- the root of the IIS virtual server is usually

 

C:\[Your IIS root]\wwwroot

 

The most likely explanation is that after installing WSS, you amended the name of your server.

 

The WSS database has already been created using the name your server had when you installed WSS. So now when you try to access WSS using the new name of the server, you will be able to access the server but not be able to access the database and thus you will get this message.

 

The simplest way to correct this problem is to re-name your server back to the name it had when you installed WSS.

 

-----------------------

 

Knowledge Base article 823287 also has a different explanation. (Although a) is similar)

 

According to that article this happens if one of the following three conditions are true.

 

a) The SQL database is not running

 

b) IIS is configured to run in IIS 5.0 isolation mode

 

c) The account that is used by the application pool does not have the required permissions to the SQL Server database.

 

For more information, please go to

 

 

(It may be that later versions of this KB include my original reason above as d))

The latest link is listed in the MS Articles section of this FAQ (via the Useful Documents Menu Line)

Yes.

 

But you then need to install WSS to a location other than the default virtual server because Class Server can only use the Default Web Site in IIS.

 

Full details of this are in KB 821501 (18th June 2003)

 

(included in the FAQ to make this information searchable)

 

I'm afraid that we don't support migrating STS 1.0 sites that are based on customized schema files.  Our recomendation for this scenario is to backup
your STS 1.0 site as usual and then edit the FWP files that smigrate generates to convert your custom list types to their closest STS v1 built-in
list types. 

 

For example:

 

1. Use smigrate to backup each individual STS v1 site. 

 

 

2. Use a Cabinet decompression utility such as EXTRACT to decompress all of the files out of the FWP file.  You can get the EXTRACT utility from the Microsoft CAB SDK at: http://msdn.microsoft.com/library/en-us/dncabsdk/html/cabdl.asp, although
any utility that can decompress CAB files will suffice. 

 

 

3. Browse to the "files" folder and open the manifest.xml file.

 

4. Change any custom list type entries to built-in list type entries.  For example, to turn the custom list type into a Links list type, change:

 

<List Name="some name" Title="some title" BaseType="0" Type="500" Url="some
url" Version="1">

 

to

 

 

5. Save your changes.

 

6. Use a Cabinet compression utility such as CABARC to compress all of the files in the "files" folder into a FWP file.  You can get the CABARC utility from the Microsoft CAB SDK at:http://msdn.microsoft.com/library/en-us/dncabsdk/html/cabdl.asp, although any utility that can generate CAB files will suffice. 

 

 

7. Use smigrate to restore the fixed FWP file to a WSS v2 site. 

 

 

Note that each site has its own manifest file.  If you don't use the "-e" switch with smigrate during the backup, then smigrate will also backup all
of the sites below the one you specify.  If that happens, you will need to alter the manifest file for each site in the FWP below the one you specified.  You can find the manifest files for a site's immediate child sites listed in the "<Subwebs>" section in the manifest file.

 

If you've created custom field types as well, then you will need to modify the manifest file to similarly convert them into the standard STS v1 field types.

 

You use the /datadir parameter - for instance

 

 

(The above is the Admin Guide example - there is more detail in the deployment scenarios section)

 

 

 

How to change the location of the Windows SharePoint Services database files

 

Original issue date: 28th June 2004

 

 

 

 

 

 

We've practiced this scenario, and while I can't promise this is the best solution I know it does work.

 

1) Reinstall SQL (We had it on a seperate machine)

 

2) Reinstall IIS and WSS.  Configure it the same way it was before.

 

3) Reinstall and web parts and web part packs you had before.

 

4) Restore ContentDBs to SQL. (DO NOT restore ConfigDBs)

 

5) Go into Sharepoint Central Admin, Manage ContentDBs and add the ContentDBs you just restored.

 

6) WSS will whir for a minute and all your sites will be back.

You are probably following the scenario in the Admin Guide for installing WSS to a single server but using an existing SQL Server 2K rather than doing the default installation and installing WMSDE.
 
As part of this installation you have probably selected "Predefined" for the security account for the Application Pool (possibly because you got an error when you tried to specify "Configurable" so you when back and chose the other option). This predefined account was "Network Service".
 
You'll then get the message covered in this item - i.e.
 
"Login failed for user 'NT AUTHORITY\NETWORK SERVICE'".
 
The solution is that you need to give NETWORK SERVICE 'Database Creation' rights. The problem is to find NETWORK SERVICE to enable you to do this.
 
1. Go Back in your browser (once)
 
2. In SQL Server Enterprise Manager specify Database Creation rights for NETWORK SERVICE after you've found it hiding away in IIS_WPG Local Groups.
 
3. Open the browser again and re-try that OK.
 
This time things should be fine.
 
Note: Of course the wise thing is to set up SQL Server correctly before you start the WSS install at all. Despite the order in the Admin Guide having a bit of WSS install followed by a bit of SQL Server install followed again by a bit of WSS install, doing ALL the SQL Server bits first and including assigning those rights to NETWORK SERVICE must be the better more organized way.
 

 

This is what either Nikander or Margriet Bruggeman had to say (slightly edited)

 

- Download the template pack of your choice (in our case, we've installed the Dutch language pack).

 

- Execute stspk.exe

 

- The language pack is successfully installed.

 

- After this, when you create a new WSS site you can choose the language in which the site will be created.

(from the ones for which you have added a template!)

 

 

Note: An easy way to check if you've installed another language pack is to check out

 

[drive]:\Program Files\Common
Files\Microsoft Shared\web server extensions\60\TEMPLATE

 

you should see two [locale] folders there, in our case English and Dutch, 1033 and 1043.

 

 

You need to install the Sharepoint Multi Language Pack from the office update site onto the server where you are running the non-English language WSS installation.

 

The direct address for this is here

 

 

(Microsoft Windows SharePoint Services 2.0 Language Template Pack)

 

 

This is the statement needed

 

STSADM.EXE -o addtemplate -filename "<template file path>" -title "<template
title>"

 

Note that this applies to all WSS site templates you want to use in SPS 2003 not just these application templates.

 

(Thanks to walterd for posting this statement in a public newsgroup)

Michael Long had the problem that

 

 

The reason turned out to be that

 

"On our production server (SQL 2000 SP4), TempDB was, for some reason, set to Database Compatibility Level 7. As soon as we set it to 8, we were golden."

 

 

If you open SQL Server Enterprise Manager then right click a database name then choose Properties then the Options tab you'll see the compatability level. For SQL Server 2000 this is 80 by default. Setting it to 70 makes it function like a SQL Server 7.0 database. Not exactly, but enough to mess up an application that requires 80 level compatability.

 

Microsoft do not recommend having WSUS and WSS on the same server and would prefer that you use two different servers.

 

If you only have one server available, then it is possible provided you install WSS in "server farm" mode. In this way, WSS won't automatically extend the default virtual server (which is used by WSUS as well).

 

You can then create a new virtual server in IIS and extend it using WSS. In this scenario, WSUS will run as the default virtual server while WSS will run as a second virtual server of the same machine.

 

 

 

 

If you install Microsoft SharePoint on the same server that is running WSUS, you might get the following issues:

 

• An "Access denied" message appears when Automatic Updates tries to update itself, and the latest Automatic Updates will not be running.
 
• On the Home page, you a message appears warning you that the SelfUpdate service is not available.
 
If client computers are not running the WSUS-compatible version of Automatic Updates, they will not be able to receive updates through WSUS.

 

To resolve this issue

 

1. Grant Anonymous access (Anonymous Auth) to the Default Web site, ClientWebService and Selfupdate v-roots in IIS.
 
2. Exclude specific requests from being intercepted by the SharePoint ISAPI DLL by doing the following:

 

a. Open the SharePoint Central Administration Site (click Start, point to Administrative Tools, and then click Sharepoint Central Administration).
 
b. Click Virtual Server Configuration, and then click Configure Virtual Server Settings.
 
c.  Click Default Web Site.
 
d.  Click Virtual Server Management, and then click Define managed paths.
 
e.  In the Add a new pathbox, set the type to excluded path. Under Path, type the following:
 
• "/iuident.cab"
 
• "/wutrack.bin"
 
• "/clientwebservice"
 
• "/Selfupdate"
 
(Exact quote - with a-e used instead of 1-5 - from the relevant section of this

 

 

"Troubleshooting Windows Server Update Services")

 

I don't know of any problems with standalone WSS of using the automatic upgrade function of Windows Upgrade.

However there IS a problem with a SharePoint Portal Server 2003 installation which although slightly out of topic is worthy of wider publicity.

 

Vinz wrote this good description of that

 

 

My conclusion is that it DOES make sense to also auto-install Office updates ...