If you're not bringing new ideas to the table, You're signing your own pink slip.

Tom Yager, InfoWorld, 04.19.04

We are live with our WSS site. The cut-over actually happened Thursday of last week. On Friday, the network team worked on the latest patches, so having multiple machines was very nice.

On the to-do list now is migrating legacy content into the WSS lists. The ultimate goal is to have our content in the search results, but keep our existing user interface. I've written a console program to syncronize a list (and other list activities like viewing the schema and contents). I'll try to post the concepts later this week.

Now that you have your PowerPoint presentation ready using the Sharepoint template, here is a tip about presenting and viewing your speaker notes.

I have a few overview/training sessions coming up, so why not use the WebPart user interface look for the slides. Download the WebPart-inspired PowerPoint template (created in PP 2003).  SharePoint.pot (35 KB)

A few items about searching with WSS (not Portal) that are worth remembering:

• SQL Server is required. WMSDE does not support search.
• To search non-office file types, an IFilter must be installed on the SQL Server machine.
• Acrobat IFilter: http://www.adobe.com/support/downloads/detail.jsp?ftpID=1276
• If you already have Acrobat files in the system, you need to rebuild the full-text index. In SQL Enterprise Manager, expand the content database. In the Full-Text Catalogs node, right-click on the catalog (ix_databasename) and choose Start Full Population. 
• Configuring WSS to display Acrobat (and other) icons in search result: KB 832809

I was refering to the production server via two different names (//MachineName and //portal.company.net). The web-service based operations (FrontPage, WPSC) would not work.

I found a few different KBase articles that lead me to an answer. 830342 discusses adjusting the virtual server to match the host header name. 832816 discusses the inability of WSS to find a server instance.

In IIS Admin, I added portal.company.net to the Web Site Idenfication for the Virtual Server:

- Right-click on virtual server (i.e. Default Web Site) and choose Properties
- On the Web Site tab, click Advanced
- In the "Multiple identies for this Web site" section, Click Add
- For IP address, choose the same setting as the existing entry
- For TCP port, choose the same setting as the existing entry
- For Host Header value, enter [portal.company.net]

This post echoes my experience...

My default.aspx page has four parts.  Everything looks and works as it should.

I added a new part. This part has client-side script that uses the WPSC to read and save a custom property. It does not work. (Here we go again...)

What I've discovered is that the WPSC is using the web services (in this case, GetWebPart) to communicate with the server. The call to this service is failing with a status of 500 - Server error. (Very helpful message, don't you think!!)

So, I attached the debugger to the iexplore process and trapped the SOAP messages. The response the the GetWebPart call is a soap:Fault with an error string of:

A Web Part or Web Form Control on this Web Part Page cannot be displayed or imported because it is not registered on this site as safe.

I found the Web Part Maintenance page, which is located at /_layouts/1033/spcontnt.aspx. This page lists all the web parts on the specified page and allows you to “close” or delete them. Very useful.

In my case, however, all of the custom web parts are listed as Error!!!

So, after four hours, I'm lost.  How in the world can I see the parts if they are not safe?

Help.  Please.

That thud you heard was my next web part crashing...

I'm converting the Personal Web Links part from SQL Digital Dashboard v3 (DDv3) to Windows SharePoint Services (WSS). The effort was not very difficult: a few CSS class name changes, a custom property that ShouldSerialize, referencing WPSC instead of DDSC, removing obsolete JavaScript functions, updating the XSL from the “TR/WD-xsl” namespace to the “1999/XSL/Transform” namespace. Everything looks good on my development machine, but other users saw nothing.

My debugging method of choice is the ASP.Net trace feature. In web config, I set the trace options:

    <trace enabled=”true” pageOutput=”true” localOnly=”true” />

This will dump a bunch of information at the bottom of the page. (WARNING: Do not do this on a publicly accessible machine. It will compromise security.)

In my web part, I include a call to Context.Trace.Write at the beginning of each routine. In the catch blocks, I call Context.Trace.Warn(ex.ToString). This puts the entire exception into the trace output. Plus, it avoids the WSS error page (“The [Name] Web Part appears to be causing a problem.“)

My exception output indicated an error accessing C:\WINDOWS\temp\faqvgg2l.dll(??). Thanks to the stack trace, I was able to determine that this dll contains the script embedded in the XSLT in an msxml:script tag. Fortunately, that function can be moved into the web part assembly, so I'm on my way.

I found a couple of tips from the microsoft.public.sharepoint.* newsgroups and I'm posting them here for future reference:

Newsgroup: microsoft.public.sharepoint.windowsservices
Subject: RE: Cross-site announcements
Date: Wednesday, April 07, 2004 4:22 AM

Please follow the steps below:

1. Open and edit the subsite page in FrontPage 2003.
2. Select Insert-->Database-->Data view-->Manage catalog.
3. Add a new catalog and type the main site URL in "Location".
4. After that, you can see all the data in the main site.
5. Drag the announcement list from the "SharePoint Lists" to the sub site
page.

UPDATE: Jan Tielens went further - he actual did this and included screen shots! Thanks Jan.

---

Newsgroup: microsoft.public.sharepoint.portalserver.development
Subject: Re: Re-Ghosting an Unghosted .ASPX Page
Date: Monday, March 29, 2004 7:58 AM

The ghost page in SPS 2003 means using the template page directly. The ghost settings will be saved in the "Docs" table. ... For this item, there is one column named Content. By default, the value for this column is "null", which means SPS will get the information from the Template. However, after we edit the page in FrontPage, SPS will save the page information to this column. In other words, SPS will use the data in the database and ignore the information from the Template.

For the default sps page, we can reset the value with the SQL commands below:

--select the portal database
use sps1_site
go
--retrieve the page id
SELECT ID FROM Docs
WHERE (leafname= 'default.aspx') 
    AND setuppath like '1033\SPS\default.aspx%'
go
--set the content to null
UPDATE Docs
SET Content = NULL
WHERE (Id = '{A3DE463E-D6E9-4A8C-A2D2-8D49562442B7}')
--please replace the id with the value on your side

I posted a new article to the SharePoint blog:

A description of the code and HTML to replicate Microsoft's Tool Pane user interface. Sample code is included.