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.

We "launched" the beta site yesterday. The beta group has 25 users, all in the IT department, including the all-important help desk and training department. The "site" is really just one page -- and it contains only what is on the current home page. We don't want to throw new things out yet.

The page has three web parts, plus a fourth in the virtual server gallery. Two more parts are under development and will be added next week. These parts:

Announcements

Yes, I know that announcements are included. We have two years worth of announcements in the current system that don't really fit in the default announcement list. Also, we don't want a different interface for the end users, so we just brought over the existing code.

That code is from the old SQL Server Digital Dashboard. (That is a story for a different day!) The web part is just a DIV tag and a bunch of client-side script. The script uses the MSXML dll's to pull the announcement data from SQL (using SQLXML) and an XSL stylesheet from the legacy web server. The script runs the transformation to the innerHTML property of the DIV.

Long term, we'll migrate this data into a WSS list so that it is included with the search results. I expect that I'll need to keep the existing format, so I'll be using another custom part, or a custom view if possible.

Corporate Links

This is just a WSS list that is populated with specific links to our corporate websites. The end-users can only view this. The fun thing about this part is that I wrote a small .Net console application to populate the list using the WSS Web Services. (That console app will most likely grow to be the conversion program for the announcements.)

Intranet Navigator

This is the part with the custom toolpart. The top-level "units" of the organization are displayed. Click on one and it expands to show the child units. The other top-level items are then hidden. The tool pane allows you to select which down-level items are displayed in the initial view.

Department Roster

This is just a fancy phone list. Each of the department pages has this part to show their members. The part reads an SQL table related to the HR system, so the built-in members part was not used.

Our first feedback meeting is this afternoon.  I hope it goes well!

Steve Clarke, in my comments, points out a few other sites with information about CSS in WSS.

The same reference is over here:
http://www.sharepointcustomization.com/resources/tipstricks/wss_cssguide.htm

And for something even cooler, check out this version. Hovering over an element reveals the style:
http://www.frontpagedevkit.com/wss/articles/themes-custom2.htm#Identifying_the_styles_that_change_key_elements

Thanks Steve!!

I was looking throughout the SDK help file for these CSS Class Definitions and never did find them!! Of course, now that I've scoured the source of many pages, I find it...

I hurriedly wrote the post last night but did not have time to explain why.  My own little cliffhanger!

My part needs to get data from an XML file, both in “regular” mode and in “tool pane” mode. I figured that I could put the file in the ASP.Net application cache and grab it during On_Load(). This seems to be a bit different -- rather than having declared controls that show some data, I have data that defines the controls. This doesn't seem to match up well with the WebPart model.

So, I moved the XML load routine to On_Init(). But, a valuable lesson learned.

I posted a new article to my SharepointBlog titled ToolPane Customization. (I practice code re-use all the time -- even in the blog titles!) None of this is really ground-breaking, just some background on what I'm trying to do. I don't know how many parts the series will have, but I hope you'll stick around for the series.