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

 

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.

In STS v 1.0 it was sufficient to specify using the STS UI that you wanted to allow anonymous access to a web or sub web.

 

In WSS it is necessary to both specify anonymous access in the WSS UI for the web / subweb but also to allow anonymous access in IIS.

Details:

 

a) IIS

 

Goto IIS MMC, right click on the Default Web Site (or the virtual server you have extended as a WSS site), properties, click on the security tab, click on the edit button of Authentication and Access control and enable Anonymous access.

 

b) WSS

 

Site Settings
Site Administration
Top Site Administration (omit if already at Top Site)
Manage Anonymous Access.

In STS v 1.0 there were two kinds of users - domain users, who used their domain names and passwords; and local users, who were defined on the STS server as a user with a password specifically for that server.

 

In WSS there are three kinds of users. In addition to the above two kinds, there can also be active directory users. [More needed]

 

see also III.2.3; III.2.4.

In STS v 1.0 it was possible in the STS UI to specify the name and password of a local user. This happened in this form the first time this user was assigned to any STS web /subweb on the same server and caused the user to be created on the server as well as being given rights to the STS web. (When you gave rights to a user for other webs/subwebs on the same server, you specified the user as <server-name>\username and didn't specify a password).

 

In WSS it is necessary to create the user on the WSS server first (specifying a password). Only following this is it possible to give this user rights to a WSS web/subweb. In this case it is sufficient to specify just the user name (i.e. no longer <servername>/username).

In STS v 1.0 a domain user was specified for a web/subweb by writing domainname\username and not specifying a password.

 

This applied both the first time the domain user had access to part of a site and to all other times.

 

In STS v 1.0 it was also possible to specify a domain user even when the workstation itself was not part of the domain. In this case when accessing the STS site from such a workstation it was necessary to enter domainname\username and password in the login box.

 

In WSS a domain user is still specified for a web/subweb by writing domainname\username and not specifying a password.

In contrast to the situation with STS, this can now only be done from a workstation that is part of the domain in question as before being given rights to a WSS site, all users are checked to see if they exist (and no login function is included in this routine).

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"

 

 

 

Mike Fairley added the following alternative
 
As we discovered after much searching you can also save the site as a template (including content).  Then delete the original site and make a new one based on the template.
 
Thanks, Mike!

 

 

You could also use stsadm to backup the site and then restore it using a different URL.  That way you don't have to delete the old site until you are ready to do it.  You can lock the old site from having changes made while you do this process. 

 

I like this process because the rename will require a restore if it doesn't work.  It could also corrupt the database and need to be cleaned up a bit before a restore can be performed to the new or old URL.   
 
Thanks, Troy! 

To upgrade from STS v1 to Windows SharePoint Services you will have to use the smigrate.exe command line utility to first backup the STS v1 site, then restore it to a new WSS site that has no template applied.

 

Instructions for doing this are in the Windows SharePoint Services Admin Guide at

 

 

(The latest version (2) at time of writing being 2nd Sept. 2004)

 

In the admin guide find the primary topic Backup and Migration and the instructions for using smigrate are in Migrating and Upgrading Web Sites.

 

It is required that you apply Office XP SP 1 and SP 2 to your STS v1 server. You can get these from here,

 

http://office.microsoft.com/productupdates/mainCatalog.aspx.

 

Once your STS v1 server is updated to SP 2 you will need to apply a QFE patch to it from

 

http://download.microsoft.com/download/d/1/3/d1335281-d1d8-4f58-afc2-c6871e6d694f/OWS1002.exe.

 

This is described in the WSS readme file (the link to this is at http://wss.collutions.com/Lists/MS%20Articles/Grouped%20by%20Category.aspx). The patch makes it possible for smigrate.exe to get as much data from your v1 site as possible.

 

Common issues:

 

1. When you create a new WSS site to restore a STS v1 site, do not apply a template to the site. When you get to the template picker page do not apply a template.

 

2. After applying the QFE patch to your v1 server you may need to upgrade your web sites. This is done using the owsadm.exe command line utility. On your STS v1 server you can upgrade all of your v1 sites by running owsadm.exe -o upgrade -p all

(after having in a command line session negotiated your way to \program files\common files\microsoft shared\web server extensions\50\bin)

 

(above instructions from Gabe Bratton in a beta newsgroup)

-----

 

Also note that when using the -u and -pw passwords with smigrate, you may get an error message

 

 

In this case please refer to Knowledge Base article 828210 for an explanation and workaround.

In WSS it is possible to transfer a list between WSS Team Sites using the 'List Template' feature.

 

Here is the detail.

 

1. Browse to your WSS site
2. Click Shared Documents, Modify settings and columns
3. Click Save document library as template
4. Name the file documents.fwp and make Template Title Documents (for example) [Tech Refresh = (probably) .stp]
5. Optionally choose to include content (which is any documents in your document library)
6. Click OK

 

Once you have made the list into a template you can copy the template to another team site.

 

1. Browse to your WSS site
2. Click Site Settings, Go to site administration, and click Manage list template gallery
3. Right click on the link for Documents and click Save target as (to your file system)

 

Now you can go to another team site, and upload the template

into that sites template gallery. After the new template is uploaded you can click Create from the navigation of the team site and create a new document library from the template you uploaded.

 

(above instructions from Gabe Bratton in a beta newsgroup)

 

Note: According to Henrik Andersson this no longer works **with Beta-2 templates** after the Beta-2 Technical Refresh. Beta-2 templates no longer are listed in the Manage List Template Gallery (above second section 2). This seems to be because templates are now stored as .stp files and amending the Beta-2 templates from .fwp to .stp seems to correct it.

The following is quoted directly from Jerry Orman's response to a question from me.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

11.0.7969.0 - WSS + SP2 (added by me 30.9 and may in fact be 11.0.7929.0 (Perry))

 

 

11.0.8000.0 - WSS + post SP2 rollup (KB900929)

 

 

 

 

 

 

 

 

 

 

Thanks as always to Jerry.

 

Note that the question he was answering concerned using smigrate to upgrade from Beta-2 to Beta-2 Tech Refresh.

 

The key parts of the general answer are the first two paragraphs of his reply (in the web site version in red).

 

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

 

 

 

You can run it from your local WSS server but
specify the remote url for the source site.

 

smigrate.exe -w German_Web_site_URL -f backup_filename -e -y -u user_name
-pw password

 

 

Create a new site on local server, don't apply site template then:

 

smigrate.exe -r -w Local_Web_site_URL -f backup_filename -u user_name -pw
password

 

 

Saurabh Nikumbha adds the following comment on smigrate
 
The smigrate utility creates a new backup set (.fwp file) everytime the size increases beyond 25MB. So if the size of your site is 40 MB then be prepared for one backup set of 24.99MB and the other of 15.01 MB.

 

Also the restore using 2 backup sets means delay and potential data loss. 

Microsoft have a (long) Knowledge Base paper on this at

 

 

 

So avoid both of these if you think that you will later be "upgrading" to SPS 2003.

 

Microsoft have a KB Article on this at
 
http://support.microsoft.com/default.aspx?scid=kb;en-us;824877

 

"How To Integrate an Existing Windows SharePoint Services Installation with SharePoint Portal Server 2003"
 
(ver 2.2 August 30th 2004)

WSS makes this process both clear and easy to do. The steps are as follows

 

Open a document library; click on the arrow at the right of the document name; click on Check Out.

 

Then Open the document; amend it; save.

 

Then click on the arrow at the right of the document name; click on Check In.

 

Fill in comments as to why... OK.

 

 

SharePoint supports two kinds of check-out:

 

This is the explicit check out . 

 

This holds a lock on the document whether you have it open for edit or not.

 

 

You get this feature implicitly. 

 

If you open a document for editing, you get a short term lock on the document to prevent other people from editing the doc while you are. 

 

The Office client applications refresh this lock periodically as long as you keep the document
open.  Once you close the document, your short term check out is released.

 

 

Shawn Ort suggested adding the following information (received from Microsoft support) to this item

 

Q: What is time period for the short term lock message?

 

A: Every three minutes
 
Q: Is there a difference in file locking when accessing document for editing over the Internet or internally?

 

A: No. It will be treated the same

 

Q: What happens if the Internet session is terminated before it releases a document?

 

A: If the session is terminated for any reason, WSS does not receive short term lock every three minutes, after 10 minutes WSS will release the document

 

Thanks, Shawn!

This is mentioned (*) in the Administration Guide.

 

 

The key details follow.

 

- One virtual server is configured with Integrated Windows Authentication and an internal address

 

- The other virtual server is configured with a different authentication type (probably Basic Authentication + SSL) and an external address.

 

Both these point to the same content.

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

 

To confuse us the SharepointTSAdmin.chm (Ed: RTM version of Admin guide not yet checked to see if identical) expands on this by saying that the two virtual
servers must be *on separate boxes*

 

This is in fact not the case.

 

Ed Lee using instructions he got from "Sabre Lighter" did so by following the instructions in the SPS Administrators Guide.

 

 

One of his virtual servers uses Windows Integrated Authentication and the other uses Basic. (as above).

 

This also worked well for another newsgroup member. (On receiving just the above instructions from Ed)

 

 

Unlike STS 1.0 which always used the same administration port number, WSS generates a random port number as the administration port.

 

If you are not happy with the random number, you use the following command line command to alter it (to 1234)

 

stsadmin.exe -o -setadminport -p 1234

 

Sebastian Seidel adds
 
If you want to know which port is used:

stsadm -o getadminport

 

This might happen when you install WSS or when you try to extend a virtual server.

 

The error message (which is very long) starts with "Setup has detected that FrontPage Server Extensions or SharePoint Team Services 1.0 is installed on the default virtual server. These must be removed ...."

 

To solve this,

 

Either

 

a) Remove FP 20002 Server Extensions from the virtual server (if they are present)

 

 

On the Server Administration Page for FP SE 2002

 

 

Or

 

(If they are not present)

 

You need to delete the hidden folder _vti_pvt\service.cnf in the content directory of the virtual server

 

(Information from the betaplace site)

 

Stop press: the link no longer works. Try hunting for the Content Editor Web part on the www.wssdemo.com site. (Thanks Maggie)

 

Open the survey's "Overview.aspx" page in Frontpage and do a search for "Survey Description"

 

once found scroll along that line until you find the following:

 

"ListProperty Select="Description" "

 

after this put:

 

AutoNewLine="TRUE"

 

save the page and then have a look at it in your browser and you will see any line breaks that you initially entered into the description.

Open the Survey List and select the Overview view.

 

Then do Export to Excel.

 

When opened in Excel you will see the person who responded followed by his/her answers.

The scenario is that you have stored .pps files in a WSS document library. Just as they should they are marked with a different icon to the .ppt files stored in the same document library.

 

However when you right-click the document name and use Save As to save a copy of a .pps file to your hard disk, the file is stored on your hard disk with the same name but the .ppt extension.

 

The solution is to make the following changes in IIS.

 

1. In IIS Administrative Console snap-in, right click the entire server and select Properties.

 

2. On the "Internet Information Services" tab, click the "MIME Types" button.

 

3. Add a new MIME type.

 

4. In the Extension box, type ".pps" (without the quotation marks), and then in the "Content type (MIME)" box, type "application/vnd.ms-pps" 
(without the quotation marks).

 

5. Click OK, and then restart IIS.

 

 

Bil Simser has a blog item on this at

 

 

so go there for the screen shot (and to read other SharePoint items in his blog)

 

In brief:

 

- open the site that contains the List in FP 2003

 

- navigate to the List

 

- right-click on the List

 

- select Properties

 

- select the Settings tab

 

- click on "Hide from Browsers"

 

As Bil points out the list is still there and can be accessed by people who know the URL (and have the right permissions).

 

Bil also says that doing this will not unghost your page.

The size of a site that can be deleted is hard-coded. Any site larger than this can not be deleted.

 

This limit for site deletion is 2GB (when renaming sub-sites or folders - which gives a different error message ["The method is not allowed on this folder"] the limit is 500MB).

 

KB article 827930

 

http://support.microsoft.com/?kbid=827930

 

"Error Messages When You Delete or Rename a Folder or Site in Windows SharePoint Services"

 

describes both the delete and renaming problems

 

KB article 888505

 

 

"Description of the Windows SharePoint Services post-Service
Pack 1 hotfix package: November 13, 2004"

 

is the fix you can get to correct this.

 

 

This is covered by KB article 242578 which is
"HOW TO: Prevent Network Share Shortcuts from Being Added to My Network Places"

 

 

This naturally prevents other things from being added to My Network Places - not just WSS document libraries.

 

The Problem:

 

The server's regional setting is set to dd/mm/yyy

 

Datefields display as dd/mm/yy in FrontPages design but the web page shows dates as mm/dd/yyyy.

 

The Solution:

 

Change the xsl tag for the date field to

 

ddwrt:FormatDate(string(@Modified), 5129 ,5)

 

Ian adds -

 

It seems that if you have a web part page and don’t type in any plain html text onto the page, the code page isn’t set.

 

Assuming you have a Field called Author and you want to group according to the first letter of the Author's name.

 

The way to do this is to create another field called (say) Index and make this a Calculated type Field.

 

Then specify the following formula for the field

 

=LEFT([Author],1)

 

Then create a list which doesn't contain the Index field but which *is* grouped by Index.

 

 

Robert Cuscaden had this alternative solution.
 
"I recently had to solve this problem with a new custom list that I was making.  The custom list is to perform like a Glossary.

 

 

<Field>

<Field Name="Index" Type="Calculated" DisplayName="Index" Format="DateOnly" LCID="1033" ResultType="Text" ReadOnly="TRUE">
<Formula>=LEFT(Title,1)</Formula>
<FieldRefs>
<FieldRef Name="Title"/>
</FieldRefs>
</Field>

 

 

<ViewFields>
<FieldRef Name="Attachments"></FieldRef>
<FieldRef Name="LinkTitle"></FieldRef>
<FieldRef Name="Definition"></FieldRef>
<FieldRef Name="Status"></FieldRef>
</ViewFields>
<Query>
<OrderBy>
<FieldRef Name="LinkTitle"></FieldRef>
</OrderBy>
<GroupBy>
<FieldRef Name="Index"></FieldRef>
</GroupBy>
</Query>

 

 
 

 

Check to see if any software has blocked port 25.

 

(In the case that led to this item this was McAfee Virus Software)

 

"M" adds that there are two options to clearing this port 25 problem with McAfee.

 

1. Edit the port blocking rule to allow the w3wp.exe process.

 

2. Disable port blocking rule within McAfee VirusScan 8.0i.

You can't do this via the WSS User Interface.

 

Instead you have to go to the following directory on your server (X: = boot drive, typically C:) and run stsadm.exe

 

Directory: X:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\60\BIN

 

Command: stsadm -o enumsites -url http://servername

This is possible via the User Interface.

 

(while in Top-level site)

 

Site Settings
Go to Site Administration

 

(in Site Collection Administration)

 

View Site Hierarchy

You browse to the (Meeting Workplace) site and -

 

1. Click 'Modify This Workspace', select Site Settings

 

2. Click 'Go to Site Administration'

 

3. Click 'Delete this Site'

 

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

 

Note that removing a meeting from a meeting workspace is at this section of the WSS SDK

 

 

This is needed in the following case -

 

"Meetings you create through an events list are not canceled or deleted when the associated event is deleted, and it is not possible to cancel or delete a meeting from a Meeting Workspace site through the user interface."

 

Folders that have been uploaded to document libraries where the folder has a name beginning with _ (underline) are not visible when the site is looked at in My Network Places.

 

Change the name of the folder by removing the _ and they become visible.

 

Note however that if you do rename the folders, any links that you have previously sent out to people pointing to documents within that folder won't work.

 

 

Note too that the same thing may apply to other leading characters than just "_".

 

He was getting the message

 

"cannot create or modify Web Capture. Make sure that your browser supports ActiveX controls, that you have enabled them, and that you have installed the Web Capture ActiveX control."

 

Something had changed in his environment as he had previously been able to define the web capture part.

 

 

This was caused by his having installed the Excel 2003 Viewer. Uninstalling it cleared the problem.

 

[Mike: I've had similar but different problems myself thanks to installing 2003 Viewers]

 

 

 

"I created a WSS site for my company's intranet which I customized through Frontpage. I added some images and HTML to the default.aspx and adjusted the CSS file.

 

I then saved the site as a site template and advised my users (all contributors) to create subsites based on this template.

 

Initially this worked fine and everything came across, so design of the page and webparts + the images and additional HTML / CSS."

 

Then suddenly the users using the site template no longer had images; additional HTML and CSS available to them.

 

Gerard himself provided the solution to the newsgroup after contacting Microsoft.

 

 

(Mike: This if I remember correctly also caused masses of .chm files not to open with data)

 

Shane Young's theory for this is that when WSS SP2 is installed via (Automatic) Windows Update it doesn't update virtual servers.

His solution is to run the following from the command prompt
 
stsadm.exe –o upgrade –forceupgrade
 
Shane notes that "some other symptoms I have heard for this problem is that you can not edit document or list properties and you can not apply new themes or templates".

The background to this is the problem that when you import an Outlook Contacts list to WSS, only entries with e-mail addresses are accepted.

 

There naturally becomes a desire *in Outlook* to create dummy e-mail addresses for those Contacts without one.

 

 

Open Contacts. File Import/Export. Export all contacts to Excel