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

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

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

 

In STS 1.0 you could customize the Home page to some degree. Without resorting to FrontPage you could for instance select which lists/libraries that showed up in the center and right column. Using FrontPage you could do a lot more.

 

WSS is quite a different story. Even without FrontPage you can do alot more to the look of the Home page.

 

First of all, it is important to notice that WSS allows each user to have his/her own Home page view. Looking at the top right hand corner of the Home page you will see either see a "Sign In" button, "Modify Shared Page" or "Modify My Page".

 

If it says "Modify My Page", the Home page shows your personal Home page view.

 

If it says "Modify Shared Page" it shows the view seen by other users that have not yet customized their view.

 

If the "Sign In" button is shown WSS don't know yet who you are (you are regarded as an anonymous user) and the Home page shows the shared view.

 

Note that you need enough privilges to be able to add/remove/view shared views (the Administrator site group has these privileges by default).

 

When you have signed in, the Home page defaults to the personal view. You can however change to the shared view by clicking "Modify My Page" and selecting "Shared View".

 

At the beginning all personal views equal the shared view. If you have made any personal changes, you can at any time revert back to the shared view by clicking "Modify My Page" and selecting "Reset Page Contents". Any personal amendments to the (own) Home page will be lost.

 

The stuff shown in the center and left column (in WSS now called the left and right zone) of a WSS Home page are Web Parts.

 

We can say that a Web Part is an object that is used to show/present something on Web Part pages (note that the Home page is actually a kind of Web Part page).

 

Often a Web Part is used to show the contents of a list or a document library. There are also Web Parts that can show other things (like an image). The Web part controls only the layout and appearance (i.e. the look) of the list/library, while the actual contents come from the list/document library.

 

Note that when you drag a web part onto a page (like the Home page) you are not dragging the actual Web Part, you are only creating and placing an instance of this web part. You can place multiple instances of the same Web Part on the same page. Each instance can be given its own set of properties controlling its appearance on the page.

 

In WSS you alter the Home page by placing Web Part instances on the page and by changing the way these instances of Web Parts present their information (by changing the instance properties).

 

There are in effect two main types of Web Parts. The first type is generated automatically each time a list (or document library etc.) is created. There is one such Web Part for each list in the current site. These web parts are associated with (and take their data from) this list. The other types of Web Part are more explicit and there is a special site catalog for them, the Web Part Catalog.

 

You can see these Web Parts at:

Site Settings
Go to Site Administration
Site Collection Catalogs: Manage Web Part catalog

 

Here you can upload new Web Parts. Click on any of them and you get a preview of what it does!

 

Browse to the Home page where you want to add something. If you want to add to your personal view, check that "Modify My Page" is shown in the upper tight hand corner. If you want to add to the shared view, make sure that "Modify Shared Page" is shown (change to the correct view by clicking "Modify xxxx Page" and select either "Shared View" or "Personal View").

 

Click on "Modify xxxx View" and select "Add Web Part" | "Browse". The Browse Web Part pane is now shown on the right side of the page. Web Parts (or Web Part instances) can be located on four different scopes:

 

"Web Parts available for this site" is selected by default. Just below you see a list of available Web Parts. You probably notice that some icons are yellow and some are grey. The yellow ones are the Web Parts automatically generated for the lists of the site (used to show the contents of these lists). The grey ones are other web parts as described above.

 

Lets add a Web Part instance showing the contents of the document library "Shared Documents". You can do this in two ways:

 

The first option is somewhat similar to the way STS 1.0 works and is often quicker because you can place the new Web Part instance where you want it in one go (If you use the second alternative the Web Part is placed at the top of the selected zone and you have to move it later if you want it to be somewhere else).

 

When you are done you can click the "X" next to "Add Web Parts".

 

If you want to remove a Web Part instance from the page you can either "Delete" it or "Close" it.

 

What is the difference?

 

Deleting a Web Part instance from the page makes it go away for good (only the instance, not the Web Part itself).

 

Closing a Web Part instance on the page removes the instance from the page. However the instance is not gone. It has been moved into the "Web Part Page Library" (Web Part instances available for this Web Part Page only as described above).

When adding Web Parts to a page you can then re-add closed Web Part instances when selecting "Web Part Page Library". It is important to note that we are manipulating "instances". Each instance (even when derived from the same Web Part) can have its own set of property values controlling its apperance.

So, saving closed Web Part instances for later can save some customization work. See "Modifying Web Part Instances" below.

 

When you want to Delete or Close a Web Part instance you can for instance enter "Design this Page" mode by clicking "Modify xxxx Page" and selecting "Design this Page". Then click the little triangle or down-arrow (<what is this really called?>) on the right hand side of the Web Part Title Bar. Then select either "Close" or "Delete". If the Web Part Instance does not have a Title Bar (which makes it a bit difficult to reach the triangle...), click "Modify xxxx Page", select "Modify xxxx Web Parts" and select the Web Part instance you want to Close/Delete (the Title Bar will now be visable!).

 

Note that the "Close" option may also be available for a Web Part instance without going through "Design this Page" (but, it is possible to turn this off in the "Advanced" Web Part instance parameters).

 

Also, "Close" may be available as an "X" next to the little triangle.

 

Now that we have added a Web Part instance to the page we may want to change the way it looks. When it was first placed on the page it was given a default look.

 

One of the more annoying things about STS 1.0 was that you cannot change this default look without having to resort to FrontPage. For instance, the default defines which columns are shown, the order of these colums and also the sort order. In other words, when the list is placed on the page it is given a default *view*. This is also true with WSS, but now you can actually change this view without having to use FrontPage.

 

To change the look of the new "Shared Documents" Web Part instance click on the little triangle or down-arrow on the right hand side of the Web Part Title Bar again. Select "Modify xxxx Web Part". The Web Part instance propery sheet is then shown to the right of the page.

 

There are 4 main sections of properties:

 

In WSS you can actually assign one of the views allready designed for the list or document library to the Web Part instance.

 

So, if you don't like the default view (called <Summary View>), just make a suitable view for the list first (do this on the list or document library page just as you may be used to from STS 1.0). Then you can assign this view to the Web Part instance.

 

In the "Selected View" drop-down list you will be able to select the <Summary View> or any of the views available for the list or document library itself.

 

Note that the association between a list/library view and the Web Part instance is not dynamic. This means that if you change the assigned view in the list/library itself after having done the assignment, the view of the Web Part instance will not change (when you assign a view to a Web Part instance, the view is actually *copied* from the list view into the Web Part instance properties).

 

In the List Views section you can also change the Toolbar type to be used by the Web Part instance.

 

 

Here you can change the Title of the Web Part instance (each instance can have its own Title, handy if you have multiple instances of the same Web Part on the page etc.). You can also set the height and width of the Web Part instance. The Frame State (minimized or normal) and Frame Style can also be changed.

 

Here you can hide the Web Part instance, set the alignment (left-to-right or right-to-left). You can also move the Web Part instance to another location by changing the Zone and Part Order.

 

Here you can (among other things) disable the possibility of minimizing, closing and changing the zone for the Web Part.

When you have finished changing the Web Part instance, click "Apply" to see the effect of the changes while staying in "change" mode or click "Done" to apply the changes and get back to normal mode.

 

Note the minimized/maximized state of a Web Part instance can be changed by just clicking on the little triangle or down-arrow on the right hand side of the Web Part Title Bar and either selecting "Minimize" or "Restore". The state is saved and is personal/shared specific.

 

In STS 1.0 with Web Parts not even available, it was naturally impossible to link Web Parts.

 

Linking libraries required use of a field of type Lookup (which I never found particularly easy).

 

In WSS Web Parts are available.

 

One of the hidden features of the use of Web Parts in WSS for people coming from an STS version 1 background is the ability to link Web parts to each other.

 

The following example attempts to make the use of Web Part Connections clear.

 

 

The aim of the "project" is to create a web site that contains information about the various members of a Project. The Project has members from several different locations and companies and thus it is important that members can be identified both by company and name.

 

Web Part Connections will be used to achieve this goal in a quick and simple way.

 

 

A Sub-site is created with the name of the Project (W2K).

 

In the Sub-site a couple of custom libraries are created.

 

a) Custom Library 1 - Company

 

This custom library will contain the names of the companies from which the project members are taken.

 

- amend the default field name from Title to CompanyName, retain all other defaults

 

- get rid in All Items of the Attachment

 

- sort All Items in CompanyName order

 

- add to the Company custom library the companies

 

The three (say) records in the Company custom library now contain Firm1; Firm2; Firm3

 

b) Custom Library 2 - Personnel

 

This custom library will contain the details of the people in the project such as: CompanyName; DisplayName; NetworkName; PictureLocation; Skills.

 

again amend the Title Field, this time to DisplayName

 

and then add the other fields

 

- Use Choice for the CompanyName

- NetworkName would typically be short (8?)

- PictureLocation is of type Hyperlink or Picture/Hyperlink (and is optional)

- Skills could be a 'multi-choice from a list' field or a multi-line field (possibly with Fill-in = Yes)

 

Populate the Personnel custom list making sure if you have a picture for the person that the Hyperlink is valid and accessible by all users.

 

 

Now go to the Home Page of the Sub-site (i.e. of W2K) and Click 'Modify My Page'

 

- Select Shared View

- In 'Modify Shared Page' select Add Web Parts; Browse.

 

In the 'Team Web Site Library' you'll notice your two new custom lists Company and Personnel now listed as Web Parts.

 

Select Company and add it to the centre column (for Web Parts = Left) and then select Personnel and add it to the Right column.

 

Now you need to go in 'Modify Shared Page' to "Design This Page"

 

Then Click on the arrow at the top-right of Company.

 

Select Connection/Provide Current Row To/Personnel

 

Say OK to the use of CompanyName from Company;

 

Select CompanyName from Personnel and click Finish.

 

You now have a list of radio buttons in Company none of which are selected. All items are still listed in Personnel.

 

Select one of the radio buttons in Company. If all is well you will immediately see in Personnel a reduced list of items (those only for the company selected)

 

 

Now Modify Shared page again and select 'Image Web Part' - add it to the centre column.

 

'Design this Page' and this time connect Personnel to Image Web Part specifying PictureLocation.

 

The names in Personnel now become radio buttons and when selected the appropriate image will appear in Image Web Part.

 

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

 

Readers who want another take on this (and screen shots!) are recommended to go to Ian Morrish's WSS Demo site - specifically to

 

John Jansen posted the following message in a beta newsgroup (he has given me permission to include it "as is" in this FAQ)

 

"My favorite web part is the Data View web part.

 

This part allows you to connect to almost any data source that can generate XML.  For example, I test against SQL server, Oracle, XML web services, server-side scripts, XML files located both internal and external to my web site, as well as standard WSS list data.  Once connected I just drag the data source onto a new page and start making the view look exactly as I want it to look using standard Table and formatting tools.

 

I haven't seen very many posts about this new feature set, but it is huge and very cutting edge and I have a feeling there are some really interesting issues lurking just below the surface waiting to be found.

 

Please try the following:

 

1. Open a WSS site in FrontPage

 

2. Create a new page in design view / Open an existing page in design view

 

3. Click on Data..Insert Data View

 

4. Drag the "Announcements" list from the Data Source Catalog onto the page created/opened in 2.

 

NOTICE: FrontPage will generate an XSLT table containing some of the Data Values from the Announcements list.  You are now authoring XSLT in a WYSIWYG environment.  You can add borders, conditional formatting, filters, sorting, grouping, etc.

 

Because of our leveraging WSS and Web Parts for this, you can also connect this data view to other data views.

 

Repeat the steps above after adding some announcements so that you have two data views on the same page.  Right click the first one and choose Web Part Connections.  Go through the wizard to create a connection that will filter the second view based on the ID of the first view and then view this page in Internet Explorer.

 

NOTICE: As you click to fire the connection, you will see only the data from that specific record in the second view. "

 

Note from the FAQ Maintainer:

 

 

Mick Saddler sent me this example.
 
Here's a very simple, yet I think powerful, application of a Data View that I've been using:

I have a retail client. 

 

They have a number of stores, all of which have their own Area in SPS. 

 

This Area they each call their Home Page. 

 

There is a need for them all to see the *same* Document Library from their Home Pages, and they do NOT want LINKS to a shared Document Library - they want to see the contents of the library itself. 

 

So, to do this simply, I created a Data View of a central Document Library, which itself is maintained by a central Group. 

 

With the Data View approach, the stores all see that same library, and get any 'updates' that way.
 
Thanks,  Mick!

Once again John Jansen has given me approval to use one of his very useful texts from the FrontPage 2003 beta newsgroup.

 

This one concerns the Form Web part and is very relevant stand-alone as well as in the FrontPage context.

 

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

 

The idea of a Form Web Part is to allow you to easily provide user response on a page as data to another Web Part through Web Part Connections.  The Form Web Part is very similar to the Content Editor Web Part in that you can specify the HTML source that the Web Part renders.  However, the Form Web
Part also has the ability to detect the form elements that are in its HTML source and determine which elements are possible data sources in a Web Part Connection.

The Form Web Part implements the Row Provider connection interface.  As such, it has the ability to pass a row of data to another Web Part.  During connection authoring time, the Web Part parses through its HTML source to find all the form elements that can provide HTML, and enumerates them as
cells in the row of data you're about to provide.  The names of the cells correspond to the names of the form elements in the HTML.

By default, the Form Web Part comes with a textbox and a submit button. However, any number and variety of the following form elements can be used in the Form Web Part to provide data:

Text Boxes: 

 

When used as a data source, a text box provides the text that the user entered.

 

      e.g. <input type="text" name="T1">

 

 

When used as a data source, the check box provides the "value" attribute of the control when it is checked, and the value "off" when it is not checked.

 

      e.g. <input type="checkbox" name="C1" value="checked">

 

When used as a data source, the drop down provides the "value" attribute of the item that is selected.  In the case of multiple selections, it provides the value of a comma delimited string of all the selected values.  In the case of no selection made, it provides the value "off".

 

e.g.

             <select size="1" name="D1">

                  <option value="foo">foo</option>

                  <option value="bar">bar</option>

            </select>

Radio Button: 

 

When used as a data source, the radio button provides the
"value" attribute of the selected radio button.

 

e.g. 

            <fieldset>

                  <input type="radio" value="foo" name="R1">

                  <input type="radio" value="bar" name="R2">

            </fieldset>

Text Area: 

 

When used as a data source, the text area provides the text that the user entered.

 

e.g.

 

<textarea rows="2" cols="20" name="S1"></textarea>

Finally, FrontPage offers a great environment for working with the Form Web Part.  In FrontPage, you can insert form elements or edit the HTML content of the Form Web Part in a WYSIWYG environment, much like how you would be editing any other part of your HTML pages.  You can also connect up the Form Web Part with other Web Parts from right within FrontPage.

 

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

 

 

 

 

If the size of a Document Library is greater than 10MB, it is impossible to save the Document Library with content as a template. It is also impossible to change the 10MB limit as this is hard-coded.

 

This brief tutorial shows one simple way of getting round this problem. (This is the basic principle, but see the Hints at the bottom before you do this on real data).

 

 

Try first to save the Document Library as a template with content. When this doesn't work because it is too large, save the Document Library as a template anyway *without content*.

 

(Save it say as "Sample")

 

 

Next create several new Document Libraries based on the "Sample" Template - call them Sample1; Sample2; Sample3 etc.

 

 

Open the original Document Library in Explorer Mode.

 

Open Sample1 in Explorer Mode in other browser instance.

 

In Explorer Mode the documents are in Alphabetical order of the Name (i.e. File Name). The file sizes of the documents are also listed.

 

Go to the original Document Library.

 

Select the first group of documents (in alphabetical order) until ca 7MB of total size. Ctrl-C. (Note the number of documents you are copying)

 

Go to Sample1.

 

Ctrl-V

 

At this stage all the documents have been copied across but none of the fields you added to the original Document Library have been populated except for Office Documents (i.e. the fields for e.g. .pdf files haven't been populated)

 

 

a) Create a View in the Original Document Library that includes all the fields that need to be populated and is in 'Name' order.

 

b) Create an Identical View in Sample1.

 

Go in both cases to the Dataview version of this View (easiest is to use Create a View of type Dataview at stage a) and b)).

 

Copy and Paste carefully as a single group all the field contents for these documents from the original Document Library to Sample1.

 

 

Complete the process by saving Sample1 as a template with content.

 

 

Repeat for Sample 2, Sample3 etc. until all Documents have been transfered.

 

You will now have templates for several document libraries with content.

 

 

Next Create Document Libraries in your other server using the templates Sample1; Sample2 etc. Call the first one by the name you intend to use in this site. ("NewSample")

 

 

Finally repeat steps III and IV above in reverse - copying from Sample2 to NewSample; from Sample3 to NewSample etc.

 

 

Finally don't forget to delete the temporary Document Libraries from both servers !

 

 

Now that I've actually done this for a large document library here are a few additional hints -

 

 

i) Create a View that is of the form that you will need as described in (4).

 

ii) Specify that 'Explorer View' is the default View.

 

 

i) Create by Create + (1) template; Save; then Back, change the last character (1,2,3 or A,B,C ...) Save; Back etc.

 

ii) Create (at least) twice the number of new document libraries you think you'll need.

 

iii) Do let them appear in the Quick Launch section.

 

 

This is a major improvement because it means that in the original document library you are already positioned at the correct place for both the document transfer (from the Explorer View) and for the field update process.

 

I.e. you don't have to remember or note down which files you have already dealt with.

 

 

 

 

Almost none except you want to route incoming fax to WSS, then you need WSS.

 

 

They are stored in either a WMSDE or SQL database depending on whether you are using the Standard or Premium version of  SBS 2003.

 

The default location for the database files is

 

Program Files\Microsoft SQL Server\MSSQL$SHAREPOINT\Data

 

 

To move the SharePoint database:

 

OSQL -E -S servername\sharepoint [Enter]
sp_detach_db STS_Config [Enter]
go [Enter]
sp_detach_db STS_servername_1 [Enter]
go [Enter]

<Before you go to the next two steps. Go ahead to copy the SharePoint files from the original location (Program Files\Microsoft SQL
Server\MSSQL$SHAREPOINT\Data) to the "new location">
exec sp_attach_db @dbname = 'STS_Config', @filename1= 'E:\new location\STS_config.mdf', @filename2 = 'E:\new location\STS_Config_log.ldf'
[Enter]
go [Enter]
exec sp_attach_db @dbname = 'STS_servername_1', @filename1= 'E:\new
location\STS_servername_1.mdf', @filename2 = 'E:\new location\STS_servername_1_log.ldf'[Enter]
go [Enter]

 

 

The main difference is that SQL provides search capabilities.

 

 

With SBS 2003 Premium Edition there is a premiuminstallsteps.htm on the Premium Technologies cd that outlines the steps to upgrade the SharePoint named instance and suggest installing the Full-Text search component of SQL.. But basically in order to use Full-Text search in WSS you need to have the following

 

(answer supplied mainly by David Copeland)

 

1) The SQL Server that WSS is using must be full SQL Server 2000.. In a default SBS case that would be the SharePoint named instance.

 

2) During the upgrade of the SharePoint named instance be sure to select to install SQL's Full-Text Search option

 

3) You need to install the SQL Server 2000 SP3a on the instance that it is using.. By default again, the SharePoint named instance

 

4) Then go to Start/Administrative Tools/SharePoint Central Administration
and click on Configure full-text search and then check the box for Enable full-text search and index component

 

Something to keep in mind is that the full-text search functionality uses a technology called Ifilters to index the files..  Depending on the file types you are wanting to search you may want to look to see if there are Ifilters for them..

 

For example.  if you were uploading Visio 2002/2003 files there are the following two downloads available

 

 

 

http://wss.collutions.com is probably the most comprehensive WSS FAQ site.

 

Microsoft's site is at

 

The SBS FAQ at http://www.smallbizserver.net has a section on SharePoint.

 

The WSS newsgroup is at

 

microsoft.public.sharepoint.windowsservices

 

This differs depending on whether you are using SBS Standard Edition or SBS Premium with ISA Server 2000.

 

For Standard Edition, run the Configure E-mail and Internet Connection Wizard and check the option to publish Companyweb. You can then access the site at www.yourwebsite.com:444. If you have a router, make sure it is configured to pass port 444 traffic to your SBS server.

 

If you are using the Premium Edition with ISA Server 2000 as your firewall, Microsoft has an article and there have been at least two other successfuly used configurations:

 

Tony Su has made some recomendations at

 

 

Les Connor made some recomendations at

 

 

 

 

These problems do not occur if you installed SBS 2003 prior to November 24, 2003. However, they may occur if you make configuration changes to WSS, such as reinstalling the intranet component, after November 24, 2003.

 

There is a fix for this at

See KB article 829112 at

 

 

See KB article 829114 at

or as supplied by Ray Fong -

 

 

1. Control Panel -> Add Remove Program -> Windows Small Business Server 2003. Set Server Tools to Maintenance. Set Intranet to Remove

 

2. Control Panel -> Add Remove Program ->  Microsoft SQL Server Desktop Engine (SHAREPOINT) -> Remove. (This step is not required if you believe the SharePoint database is installed correctly.)

 

3. Delete HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SmallBusinessServer\Intranet

 

4. Delete HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\SHAREPOINT

 

(!!!!!Do NOT delete this key if you did not remove Microsoft SQL Server Desktop Engine (SHAREPOINT) in the pervious steps !!!!!)

 

5. Delete HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\Ports\Port /LM/W3SVC/4:

 

(Do not delete "Port /LM/W3SVC/1:" because it is FronPage Server Extension 2002 which is installed on the Default WebSite. If you see additional "Port /LM/W3SVC/X:", backup the keys first and then remove them)

 

6. Rename C:\Program Files\Microsoft SQL Server\MSSQL$SHAREPOINT to
MSSQL$SHAREPOINT.OLD (!!!!!Do NOT rename this folder if you did not remove Microsoft SQL Server Desktop Engine (SHAREPOINT) in the previous steps !!!!!)

 

7. Control Panel -> Add Remove Program -> Add/Remove Windows Components. Uncheck Application Server -> Internet Information Services (IIS). Click Yes to confirm removal of ASP.NET and RPC Over HTTP Proxy

 

8.Rename C:\Inetpub to C:\Inetpub.old

 

 

 

1. Control Panel -> Add Remove Program -> Add/Remove Windows Components

    a. Check Application Server -> Internet Information Services (IIS)
    b. Check Application Server -> Internet Information Services (IIS) -> FrontPage 2002 Server Extensions, NNTP Service, SMTP Service
    c. Check Application Server -> ASP.NET
    d. Check Networking Services -> RPC Over HTTP Proxy

 

2. Control Panel -> Add Remove Program -> Windows Small Business Server 2003
    a. Set Server Tools to Reinstall.
    b. Set Intranet to Install. (If Intranet failed to install, please refer to Q832880)
    c. Expand Client Deployment, set Internet Explorer 6.0 and Microsoft
Office Outlook 2003 to None (Installed).
    d. Set Exchange Server to Reinstall.

    e. Reinstall fix KB831464
    f. Reinstall Exchange Server 2003 SP1

 

 

 

 

1. Run CEICW. This will reconfigure the IIS for OWA/Remote Web Workplace/Companyweb.

 

2. Verify you can logon

 

to OWA via https://localhost/exchange,

 

to RWW via https://localhost/remote, and

 

to Companyweb via http://Companyweb

 

 

Sean Daniel had this

 

"So this one came up in the SBS public newsgroup today. How do you change the name of the CompanyWeb, so internally it doesn't respond to http://CompanyWeb, but responds to something else?

 

Well, what I ended up doing (since I wanted mine to be called http://FamilyWeb), I simply went into the DNS snap-in and created a new Host(A) record (similar to companyweb) and pointed it to the same place as CompanyWeb. Then I went into the IIS snap-in and right clicked on the CompanyWeb virtual server and chose properties, then on the advanced button on the General tab, I make sure that the virtual server answers to http://FamilyWeb on port 80."

 

You'll find the rest of this blog item here

 

 

 

Marina Roos wrote this SBS 2003 FAQ item (full of images) which is an alternative to the rename in the previous section (both retain the standard companyweb for internal SBS 2003 reasons)

 

http://www.smallbizserver.net/Default.aspx?tabid=170
 

 

 

 

Daniel writes - "I have come up with some simple steps that I think streamlines the Web Part creation process, ensuring you are up and running with a debuggable/deployable web part as quickly as possible".
 
1) Install the Web Part template for Visual Studio:

 

http://www.microsoft.com/downloads/details.aspx?FamilyId=CAC3E0D2-BEC1-494C-A74E-75936B88E3B5&displaylang=en
 
2) Create a new project in Visual Studio using the Web Part project template

 

"I find it useful to create it as part of a solution, as you will see later, when you do the deployment piece you will need to add an additional Visual Studio project."
 
3) "Setup" the project for your web part.

 

This involves setting the correct class names, namespaces, etc. to something appropriate to your web part.
 
4) Set the build path to the \bin directory of the Virtual Server where the portal where you will be running the web part is located.

 

(If there isn't one already, create it.)
 
5) Build the project.

 

This will give you a web part that simply displays the value of a property, it's what the template installed in step one gives you. The important thing is that you have now built a Web Part .DLL in the Portal sites \bin directory from Visual Studio. By doing this you have "debug enabled" the web part project.
 
6) Install the new web part into your portal using the "InstallAssemblies" tool written by Maurice Prather here:

 

http://www.bluedoglimited.com/SharePointThoughts/ViewPost.aspx?id=13

 

and give it a quick test.
 
This tool automatically does two things that often cause Web Part developers the most trouble:

 

a) Creates a valid "Safe Control Entry"

 

b) Creates a valid Web Part .DWP file

7) Take the .DWP file that InstallAssemblies creates, either by using the button on the tool UI, or looking inside the Portal Virtual server \wpcatalog directory and add it to your project.

 

This replaces the one created as part of the original Visual Studio Template.

 

Update the Manifest file so that it can now find this new .DWP file, and then take the SafeControlEntry from your Portals Web.Config file and replace the one already in the Manifest file.
 
At this point you are ready to start debugging the Web Part.

 

Place some break points, do a build, then attach to the W3WP process on the Portal server. Drop the web part onto a page and bingo, you are debugging.
 
Take this a little further by applying polish.
 
8) When you have finished your web part you can build the deployment package called a "Web Part Package".

 

Create a new Deployment Project (.CAB) inside the existing solution and populate it with the output from the Web Part project. When complete build the new project.
 
9) Finally, remove the version of the web part you added using InstallAssemblies (this is also a feature of the tool) then replace it with your new packaged version using STSADM.EXE.

 

-------------
 
At the end of all this you have an easily debuggable/deployable (and pretty) web part in under 10 minutes.

 

 

Essentially, the DateRangesOverlap CAML element doesn't *quite* operate as I would have expected it to from reading the documentation. 

Rather than returning all events that occur (that overlap) a specified date/time, the DateRangesOverlap element is designed to determine if and when the total date and time range of a recurring event set overlaps -- perhaps a better term is "includes" -- the date/time specified. 

 

Example: 

 

If today's date is 1/10/2010, and I have a recurring appt that runs from 1/1/2010 to 1/15/2010, a query using DateRangesOverlap specifying <Now /> will return the event. 

 

However, if I have a recurring appt running from 1/1/2010 to 1/5/2010, the query will NOT return the event. 

I was able to verify this in my tests. 

DateRangesOverlap asks the following question:  Do any recurring event ranges span past the date that I've specified?

It does not matter if there is a recurring event ON the date specified, only if any recurring event ranges encompass the specified date/time.

One curious thing is that issuing a query that uses DateRangesOverlap will  return all sorts of non-recurring events. 

When using DateRangesOverlap, one should also specify that only recurring events are to be returned, because the element is only designed to be used with recurring events.

That being said, I also dug around for more information about accessing recurrence events (that is, individual occurences of recurring events) within Sharepoint lists using either the object model or CAML.  Unfortunately, the consensus is that there is no good way to do this.  The recurrence events are actually created on-the-fly, and don't exist in the database the same way that a standard event might.

 

 

I.e. Upload Document; Upload Multiple Document and select the files to upload.

 

Note that Upload Multiple Document is only visible when the Client has Office 2003 (any version) installed.

 

 

Open the Document Library and select the Explorer View.

Copy/Paste (or drag and drop if it works) the files from Windows Explorer to it.

 

 

Define the document library in "My Network Places" and Copy/Paste (or drag and drop if it works) the files from Windows Explorer to it.

 

 

Use Net use to define a local drive for the document library.

 

This probably requires Office 2003 installed on the client and has the following format

 

Net use X: \\servername\xxx\doclib1

 

where the URL of the document library is http://servername/xxx/doclib1

 

(It is wise to only use names in the path that contain no blanks or strange (or foreign) characters as otherwise the net use statement often seems to have problems.)

 

Following the specification of local drive X:, files can be copied to the document library it represents by Copy/Paste (or drag and drop if it works) from Windows Explorer.

 

 

 

 

The following code was described as a generic way to upload a file into any web folder (doesn't have to be WSS) using ADODB. It can presumably be amended for a batch of files.

Set objRecord = New ADODB.Record
Set objStream = New ADODB.Stream
objRecord.Open strFile, "URL=" + strUrl,
ADODB.ConnectModeEnum.adModeReadWrite,
ADODB.RecordCreateOptionsEnum.adCreateOverwrite,
ADODB.RecordOpenOptionsEnum.adDelayFetchStream, Sharepoint2003USerName,
Sharepoint2003Password
objStream.Type = ADODB.StreamTypeEnum.adTypeBinary
objStream.Open objRecord, ADODB.ConnectModeEnum.adModeWrite,
ADODB.StreamOpenOptionsEnum.adOpenStreamFromRecord
objStream.LoadFromFile (FileName)
objStream.Flush
objStream.Close
objRecord.Close

 

 

If you want to use a tool for this, a couple of suggestions are

 

a) DavCopy at http://www.bluedoglimited.com/Downloads/pages/DavCopy.aspx
or

b) Kimmo Forss' toolset at http://www.gotdotnet.com/workspaces/workspace.aspx?id=6996fb17-2a54-4607-983b-35c7697baa53

 

 

 

 

(http://www.snapfiles.com/get/replicator.html)

 

but these days he's recommending the new SyncToy from Microsoft (http://www.microsoft.com/windowsxp/using/digitalphotography/prophoto/synctoy.mspx).

 

He says it's a "very clean tool, free, and pretty easy to configure. Plus lots more settings for copying to/from Sharepoint."

 

(The translation here is mine.)

 

 

1. Access the WSS server and create a new sub-directory (asp) under the WSS Site (example e:\webroot\office)

 

2. Copy the ASP files to this sub-directory (e:\webroot\office\asp)

 

3. Access Programs / Administrative Tools / SharePoint Central Administration

 

4. Select 'Configure virtual server settings in the "Virtual Server Configuration" section of the page.

 

5. Select a virtual server (default "Default Web Site").

 

6. Select "Define managed paths" in the "Virtual Server Management" section of the page.

 

7. In the "Add a New Path" section at the bottom of the path do two things

 

a) add /asp to the Path box

 

b) select the "excluded path" radio button.

 

8. OK

 

After doing the above the path will no longer be administered by WSS and the ASP application will run.

 

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

 

 

 

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

 

Scott Townsend was happy with the above solution but for the fact that he could not see the new /ASP folder when he accessed the web in Front Page 2003.

 

Ian Morrish came to the rescue with this.

 

I get around this problem by creating another virtual server, extend it with FrontPage Server Extensions 2002 and set the Home Directory to http://site/asp.

 

You can then open this site in FP to maintain your ASP code.

 

 

He notes that it took him a serious week of Google and hacking to find out how to do it!  I (finally) found a VBScript example that worked (courtesy of Don Badowski, http://www.codecomments.com/archive300-2005-4-452832.html) and have converted that to C#.

 

I've not checked it (not my sort of thing) so if you have problems with the solution can you post them to the .windowsservices.development newsgroup and if you want me to change something here, please mention my name in the subject line or send me e-mail to wssfaq at hotmail

 

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

Description: I wanted to be able to automate the process of creating a web folder shortcut to a sharepoint site on the filesystem.  We use Sharepoint to manage our project documentation, and our users wanted to be able to navigate to a sharepoint site via the filesystem, rather than having to "remember" a URL or have to use "My Network Places" all the time.  It would also give us control over the list of common site shortcuts.

 

Solution: I converted the original VBScript function to C#.  I created a folder on our shared network drive that I use to store web folder shortcuts to our WSS sites.  I am going to set this folder as the default folder for all Office programs, so that users can select their web folder from the list and save directly to their Sharepoint site.  Following is the complete code for the solution.  I've included the original VBScript lines as comments for reference.

 

using System;
using System.IO;

 

namespace OPS.Sharepoint
{
        /// <summary>
        /// Sharepoint utilities class
        /// </summary>
        public class Utils
        {

 

                /// <summary>
                /// Create a Sharepoint web folder shortcut
                /// </summary>
                /// <param name="siteURL">URL of the shortcut site</param>
                /// <param name="siteName">Name of the site (used as the shortcut name)</param>
                /// <remarks>
                /// Original source (VBScript and JScript):
                /// Author: Don Badowski
                /// http://www.codecomments.com/archive300-2005-4-452832.html
                /// Thanks Don!!!! You saved me about 2 weeks work!  Wish I'd found this a week ago lol
                /// </remarks>
                /// <example>
                /// CreateSPSShortcut("c:\temp", "http://portal/sites/myteamsite/", "My Team Site")
                /// </example>
                public static void CreateSPSShortcut(string urlFolder, string siteURL, string siteName)
                {

 

                        // Create folder for shortcut
                        string folderPath = CreateFolder(urlFolder, siteName);

 

                        // Create ini file
                        string iniFilePath = CreateIniFile(folderPath);

 

                        // Create .lnk file
                        string linkFilePath = CreateLinkFile(folderPath, siteURL, siteName);

 

                        // Set ini file attribs
                        SetIniFileAttributes(iniFilePath);

 

                        // Set folder attribs
                        SetFolderAttributes(folderPath);
                }

 

                /// <summary>
                /// Create the binary link file
                /// </summary>
                /// <param name="urlFolder">Folder to put the link file</param>
                /// <param name="siteURL">URL target of the link file</param>
                /// <param name="siteName">Shortcut link name</param>
                /// <returns>Full path to the link file</returns>
                /// <remarks>
                /// The name of the link file *must* be target.lnk, otherwise the shell extension won't recognise it
                /// </remarks>
                private static string CreateLinkFile(string urlFolder, string siteURL, string siteName)
                {
                        const int URL_CUTOFF = 44;

 

                        // Create the target.lnk file
                        string filePath = urlFolder + "\\" + "target.lnk";
                        FileStream fs = new FileStream(filePath, FileMode.Create);

 

                        // Create the binary writer object
                        System.Text.Encoding encoding = System.Text.Encoding.Default;
                        BinaryWriter w = new BinaryWriter(fs, encoding);

 

                        //'Line 1, 16 bytes
                        //bString = Chr(&H4C) & Chr(&H00) & Chr(&H00) & Chr(&H00) & Chr(&H01) &
                        //Chr(&H14) & Chr(&H02) & Chr(&H00) & Chr(&H00) & Chr(&H00) & Chr(&H00) &
                        //Chr(&H00) & Chr(&HC0) & Chr(&H00) & Chr(&H00) & Chr(&H00)
                        w.Write((char)(0x4C));
                        w.Write((char)(0x00));
                        w.Write((char)(0x00));
                        w.Write((char)(0x00));
                        w.Write((char)(0x01));
                        w.Write((char)(0x14));
                        w.Write((char)(0x02));
                        w.Write((char)(0x00));
                        w.Write((char)(0x00));
       &