Web Part Installs on SharePoint 2003 in environments where you don’t control the Database

In a continuing series of mishaps involved with a very abstracted permissions environment where one group controls all admin rights on the server, except for the group that controls all admin rights on the Database, I discovered today that if you need to install a Web Part in SharePoint 2003, you need to do it on the Web Server(s) in question while running in the context of an account that has proper permissions (I assume at least DB Creator & Security Admin if not also System Admin) within the SQL Server where your Configuration Database lives.

What we were seeing was that the Office Web Parts installer and two MSIs for custom web parts ran. The Office Web Parts installer reported that it had installed correctly. On the other hand, the MSIs reported an install error and referred to the log which was essentially empty. (MSI Web Part Packager installer logs go in C:\Documents and Settings\\Local Settings\Temp\wppackager.log.) Some 3rd party manufacturers of Web Parts do support this issue (in comparison to Microsoft, who don’t seem to report this issue in any KB article), and suggest using stsadm to install instead.

We then tried using stsadm.exe to install (some Microsoft third party web part vendors report the unhelpful MSI install failure message, even though Microsoft doesn’t) the MSI packages, and instead got the familiar Configuration Database connectivity error that refers to KB 823287:

Cannot connect to the configuration database. For tips on troubleshooting this error, search for article 823287 in the Microsoft Knowledge Base at http://support.microsoft.com.

Here’s a link I found very helpful to help explain/troubleshoot the issue.

Unfortunately, at this client, I will now need to punt to a policy question about how to approach the install next, but hopefully in your situation you’ll be able to just use an account with the right permissions to do the install.

I have been negligent – bullet updates, but I’ll get around to the major stuff later

Since I fully expect next month to be a slow month, I should be able to catch up a little.

Anyhow:

  • I am installing the Release bits of Microsoft Office 2007. I don’t know if I’ve already plugged CCleaner but I’m doing so again. I needed it because Office 2007 Beta 2 Technical Refresh didn’t uninstall entirely cleanly. An add-on I’d installed after the original install had to be manually removed, but it didn’t show up in my Add/Remove Programs, so CCleaner was instrumental in my being able to find an uninstall the bugger so I could go ahead with the install of the Release version.
  • It turns out that the extended problems I had properly creating the Shared Service Provider portion of MOSS 2007 were due to two factors:
    • I had neglected to complete the MOSS 2007 Beta 2 TR install properly. I’ll go back to that article and add the details in, but instead of running the configuration wizard right away, I should instead have uninstalled Windows Workflow Framework from Add/Remove Programs, installed the .NET 3.0 Framework RC bits and then run the connfiguration wizard.
    • I wasn’t thinking about permissions and rights properly so was creating the app pool for the Web Application that was to support the SSP with Network Service as the ID, which of course has a different PID/GUID on each machine so wasn’t mapping to the Network Service ID on the database server (2-server setup). What I should have done was create the app pool with a domain account ID that had sufficient perms on both boxes and on the SQL Server itself. It never ceases to amaze me how my mind will just drop stuff. This stuff holds for SharePoint 2003 too and I know that cold, but I just didn’t make the leap to apply it to my knowledge of MOSS 2007. Duh.
  • So I need to blog permissions articles that have been popping up on Technet/MSDN lately.
  • I also need to update on my/my company’s progress in fixing (or trying to fix) the Full Text Search in our production deployment of SharePoint 2003. Client still not interested in calling Microsoft Product Support Services. Now it looks like it might have to do with the Cluster configuration and the FTDATA folder. If it isn’t that, not only am I, but my company is tapped out and it is totally time to stop playing political games and djust call Microsoft PSS.
  • There are some links I found to training materials that I’ll also blog (I’ve been doing research on behalf of my client’s Training department).
  • I’ll be working on customizing my company’s portal soon, and doing a little mini-app with a guy based in the Richmond office, so we’ll see how well the development/customization process on MOSS 2007 collaborates. More updates there, hopefully by next week.

Anyway, been terribly busy, too busy, perhaps, to blog, but I’ll try to return to it, because taking notes is important to me, and putting it here means I can find it whereever I have Net access, and maybe it’ll help out other folks too.

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

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.

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.

Server Accounts, Changing them, Permissions Issues – Followup

In my previous post (opens in new window), I said I’d let you know how it went. Turns out for various reasons we didn’t get around to testing my assertions until this morning.

It went fine. I was right about what was broken and what needed fixing. The implementation of the fix and the continued procedure to change the rest of the service accounts in the QA lab went off without a hitch, so soon, we get to do it Production too.

Database Migration breaks WSS/SQL Server Full Text Search

So here’s a little-known issue with SharePoint and Full Text Search:

On Joel Oleson’s blog (if you don’t know who this guy is and you’re in SharePoint Operations, find out quickly. Aside from Bill English [the man, his blog], he’s the other Man in SharePoint Managment/Operations – both of these guys regularly present at TechEd conventions), I found a blog entry about how, if your Full Text Search (that’s the one that works in Windows SharePoint Services, and is provided through the back-end SQL Server) isn’t working, and you migrated the database from a different server, the reason would be, possibly/probably, that you migrated the database from a different server.

Yes, I mean either with SPSBackup.exe (which should be your friend by now if you’ve been doing a lot of this and you want to keep the SharePoint Portal Search Index between migrations) or normal SQL Backup/Restore and file operations.

So anyway, there are a couple of stored procedures in the blog you should use to restore your Full Text Search. As far as I can tell, these are either SQL standard stored procedures, or, more likely, SharePoint-installed stored procedures.

Also, rather like part of my previous blog entry, the fix is essentially “turn it off, turn it on”, with some curve-balls in there if things don’t go as expected. It turned out to be thorough enough for us, so maybe it’ll be thorough enough for you.

Since I had to puzzle the blog entry out a little bit, I’ll write what I understood of how to do this here.

  1. Mr. Oleson recommends restarting your SQL Services, but we didn’t find this completely necessary.
  2. Run the following stored procedure: exec proc_DisableFullTextSearch
    1. If you get an error about there not being a Full Text Catalog, then run the following in SQL Query Analyzer and start Step 2 again:

      USE [databasename]
      sp_fulltext_database enable

      Where [databasename] is the name of the _SITE database you’re having the issue with. [But don’t actually type the [] brackets in there or your geek compatriots will laugh at you.]

  3. Run the following stored procedure: exec proc_EnableFullTextSearch

So that should be it. The procedure, as I said, is mostly just turn off, turn on again.