Search Link Salad

Stuff for me to remember based on current research (more about searching in WSS 2003, but am finding links related to future configurations of SPS2003 or MOSS 2007 search):

Some documents are not returned in the search results when you use the Advanced Search feature in SharePoint Portal Server 2003 to search for content that has a custom property

How to determine if Windows SharePoint Services or if FrontPage Server Extensions is in use in IIS

MOSS 2007 Beta 2 Technical Refresh Install – Slipstreaming the Technical Refresh and by the way, you’ll be needing these exact .NET/WWFX installs too

Okay, so Wednesday and Thursday were my days for installing MOSS 2007 Beta2TR on our pilot servers.

I followed Steve Smith’s excellent PDF-based instructions for “slipstreaming” the Technical Refresh updates into the normal install files for MOSS 2007 Beta 2, and then prepared a DVD-ROM with those files and the .NET 3.0 CTP release, which I’d mistakenly thought were the right .NET framework and Windows Workflow Framework installs to carry out before installing MOSS 2007 Beta 2 TR.

It turned out the .NET 3.0 CTP release was the wrong choice.

What you really need are the .NET 2.0 Redistributable Framework (x86 or x64) and the appropriate install for Microsoft® Windows® Workflow Foundation Runtime Components Beta 2.2 and Visual Studio® 2005 Extensions for Windows Workflow Foundation Beta 2.2 (you choose x86 or x64 near the bottom of the web page). I found this out in the comments to this post on the A Marvellous Point blog.

With these pre-installed, the MOSS 2007 Beta 2 with slipstreamed Technical Refresh went perfectly, but I must admit I’m not done with the configuration portion of the work. Lord willing, that’s coming on Tuesday.

Update (11/27/2006)
I know that the Release bits will be out soon, but this may help folks still trying to install the Beta (which I think is still good until February 2007, if I remember correctly).

So it turns out that the 3.0 .NET framework (workflow) was the right choice, but I applied it too soon.

The best URL for the proper install procedure that I could find was on Technet, and it was hard to read and puzzle out, so here’s the read I give it. This series of steps ended up working for my MOSS 2007 Beta 2 Technical Refresh Install entirely:

The other gotcha I’ve already mentioned but it would be wise to keep an eye out for is that if you are running SQL Server on another box, then the same advice for SPS 2003 holds here, which is that your SharePoint Service accounts should be domain accounts, as should be the Identities you run your Web Applications, since you need to grant that account access on the SQL Server. Remember, kids, that the Network Service account has a different, unique, random PID on each server, so you can’t expect a Network Service on one server to authenticate correctly on another.

Web Part Packager – Link Salad

I went looking for a Web Part Packager install walkthrough with screenshots that a co-worker might find useful, but was unsuccessful. I did however find a bunch of links I wanted to save for myself. 

So if you don’t know about the Web Part Packager and you’re running SharePoint 2003 and developing/deploying web parts, learn about it! I understand from the folks at Blue Dog Limited that the tool’s going away for MOSS 2007, but I don’t have it verified. Given that 2007 is still in Beta, though, knowing about the Web Part Packager is probably still a good thing.

Without the Web Part Packager (which generates msi files for installation), you can do a Web Part deployment the CAB file way or the manual way.

You can automate a Web Part Packager build as part of your Visual Studio 2003 project(s), too, which is cool. I know at least two developers in my group who already do this.

Using WPPackager also installs an entry into the Add/Remove Programs box, which makes your install friendly to system administrators should they need to remove the web part. Speaking of which, here’s the Managing Web Parts on Virtual Servers section of the WSS 2003 Admin Guide.

Speculation – Further attempted fixes to WSS 2.0 Full Text Search

So the current situation is that despite my past posts about fixes to WSS 2.0/2003 Full Text Search, both my QA and Production environments have Full Text Search enabled, but are/were only returning results for content that pre-existed the fixes.

The Full Text Index actually existed in the SQL Server Content Database (for WSS content), and the MS Search service was running properly on the SQL Server.

Reviewing the best discussion of this sort of thing that I know for steps I might have left out,  I found out that even though WSS 2.0/2003 says it’s got Full Text Search enabled, it may not in fact be enabled.

So you go to SharePoint Central Administration, then click the Windows SharePoint Services link on the left side nav bar, and then click the “Configure Full Text Services” link and even though the checkbox is already enabled, click “OK” anyway, and let the changes be applied and go check the functionality of your search against new content.

Update: This only ended up working for me in our QA environment, which is apparently different in this respect from our Production environment (still b0rked). Oh well, there may be a call to MS support in my future if I continue to be stumped.

And scarily, for me, Full Text Search started working properly, even with new content.

Using UNC Paths to access the “directory structure” in SharePoint 2003 – Requires WebClient service running on your client computer

So for the longest time I couldn’t figure out why on some computers I could use a UNC path to get to SharePoint sites’ resources, and on others I could. Now I think I finally have the answer.

The mechanism is that if you have a WSS site (and Admin privs on that site) at a URL/URI like: http://server/sites/testsite1/, you should be able to open Windows Explorer (not Internet Explorer) and open its UNC path: \\server\sites\testsite1\. If you so so, in Explorer, you should be able to see the full “directory structure” (I put this in quotes because it doesn’t actually exist, but is a figment of your, SharePoint’s and SQL Server’s imaginations), including directory names like “_catalogs”, “_fpdatasources”, “_private”, the ever popular “images”, a directory for non-Document Library, non-Picture Library lists called “Lists”, a folder for each sub-site and a folder for each Document Library or Picture Library, various aspx pages, etc.

Using this UNC Path view, you can do normal file operations, but do be careful, since if you delete a file you probably can’t get it back.

Anyhow, I’d been finding that sometimes this UNC path worked in Explorer and sometimes it didn’t. It didn’t appear to be related to a particular user permissions set or domain login account, but changed computer to computer.

Here’s the error message I’d get when it didn’t work (click to see full size):

WebClient Error
Here’s the kind of folder structure I’d see when it did work (click to see full size):

UNC View
It turned out, after trial and error, that the real difference here was that one computer I was using was running the WebClient service (where the connection worked), and the other wasn’t (where the connection did not).

No, I couldn’t easily find it documented on Microsoft’s support sites.

IE7 Running Fine

Microsoft’s Internet Explorer 7 is out as of some time this week. It’s kinda slick. I don’t know if it’s necc’ly better than Firefox (and I haven’t tried out Firefox’s 2.0 betas), but it seems to work pretty well and seems a bit more secure (esp. about expired/unverified SSL certs) with respect to explicitly helping users figure out whether where they’re going is where they think they’re going, and other such things.

Anyway, good start, despite already having a security vulnerability.

Works okay with SharePoint 2003 and with OWA 2003.

I’ll report more on it as I have the experience to do so.

Laptop/Notebook Hotfixes for MS Virtual PC 2004 SP1

So as you may know, Microsoft and many SharePoint dev houses swear by doing development on Virtual PCs/Virtual Servers. The reason for this boils down to the fact that when you are debugging a SharePoint Web Part with Visual Studio 2003, you have to connect to the active w3wp.exe process that IIS is using and have your debugger work with that. This single-threads that process and halts/pauses it as you explore the reflected data structure states/etc.

I.e. SharePoint development doesn’t share well. I.e. Two developers trying to share the same server, while one is debugging, is ugly and crass and doesn’t belong in Kindergarten.

So the fix is to give each developer her/his own VPC to do with as he/she likes.

Anyhow, if you are doing this via Microsoft VPC 2004 SP1 (free for download these days, by the way), and you happen to be using it on a laptop/notebook, you need a hotfix (Microsoft KB 889677). If you happen to be using a laptop/notebook that’s using Intel’s 915 Chipset (i.e. some forms of Centrino chipsets), you need an additional hotfix (Microsoft KB 899525). I hear that Tablet PC owners may need a different one.

Add to this pain that you have to either find some place to download the patches that’s illicit or ask Microsoft support for the patches (i.e. risk some idiot deciding to charge you for it). I managed to find a non-Microsoft source for the hotfixes, but if you do the same, do what you can to be paranoid and cautious about the hotfixes you didn’t get from Microsoft – the reason it’s a good idea to get it from Microsoft directly is that you’re reasonably sure someone isn’t slipping you a trojan horse or something worse instead of the actual patch.

Anyhow, after installing the additional patches, VPC is flying compared to previously.