SharePoint – the good, the bad and the ugly

I’ve been messing around with SharePoint. When it works, it is a beautiful product. It is a smart file system with versioning, check-in and check-out, point-and-click workflow (eg document approval), offline support via Outlook, direct open and save from Office 2007, and more. It is an instant intranet with blogs, wikis, discussion forums, surveys, presence information, easy page authoring, and more. It is an application platform with all the features of ASP.NET combined with those of SharePoint. It is a content management system capable of supporting a public web site as well as an intranet. It is a search server capable of crawling the network, with a good-looking and sophisticated web UI. And in the high-end Enterprise version you get a server-side Excel engine and all sorts of Business Intelligence features. Fantastic.

Even better, the base product – Windows SharePoint Services 3.0 – comes free with Windows server. Search Server Express is also free and delivers all the search capability a small organization is likely to need.

What’s wrong with this picture? Here’s a few things:

  • Gets very expensive once you move to MOSS (Microsoft Office SharePoint Server) rather than the free WSS.
  • Deeply confusing. Working out the difference between WSS and MOSS is just the start. If you want to deploy it, you had better learn about site collections, applications, operations, farm topologies, web parts, workspaces, and the rest.
  • Complex to deploy. Make sure you read Planning and Architecture for Office SharePoint 2007 Part 1 (616pp); the good news is that part 2 is only 52pp. SharePoint is all that is bad about Microsoft deployments: a massive product with many dependencies, including IIS, ASP.NET and the .NET Framework, SQL Server in particular configurations, and of course hooks with Office 2007, Exchange and Active Directory.
  • Generates horrible source code. Try opening a page in SharePoint designer and viewing the source. Ugh.
  • Challenging to back up and restore, thanks to being spread across IIS and SQL Server.

I am out of sorts with SharePoint right now, after a difficult time with Search Server Express (SSX). I have a working WSS 3.0 installation, and I tried to install SSX on the same server. My setup is just slightly unusual, since I have both SharePoint and a default web site on port 80, using the host headers feature in IIS to direct traffic. The SSX install seemed to proceed reasonably well, expect for two things.

First, I puzzled for some time over what account to use as the default account for services. Setup asks you to specify this; and the documentation is a classic case of unhelpful help:

In the Default Account For Services section, type the user name and password for the default services account.

In the Search Center Account section, type the user name and password for the account for the application pool identity of the default Search Center site

Well, thanks, but I could have figured out that I have to type a user name where it says “User name”. But I would like help on how to create or select a suitable account. What permissions does it need? What are the security implications? The temptation is to use an administrator account just because it will most likely work.

Then there was the problem of creating the search site application manually. I had a go at this, helped by these notes from Ian Morrish. I set up a crawl rule and successfully indexed some content. Then I made a search, to be greeted by this error:

Your license for Microsoft Search Server has expired.

Well hang on, this is Search Server Express and meant to be free! A quick Google turns up this depressing recommendation from Microsoft:

To solve your immediate problem, however, it is suggested you uninstall WSS, MSS Express, repave your machine with a clean OS, and reinstall only MSS Express (WSS is installed with it).

Thanks but no thanks. See this thread for a more informative analysis. The user yanniemx reckons, after 10 reinstalls, that he has worked it out:

I realized it was due to using the Express version of Search and then not using the SQL install that is included in the install.  From what I can tell if you use another SQL instance it thinks you are using multiple servers and that is not allowed for the Express version.

I think I’ll just uninstall. I did another install of the full MOSS on its own server, and that one works fine. Running on a virtual machine is another good idea.

I hate the way certain Microsoft server products like to be installed on their own dedicated server. That makes sense in an Enterprise, but what about small organizations? I don’t see any inherent reason why something like SSX shouldn’t install neatly and in a reasonably isolated manner alongside other products and web applications. Equally, I am sure it can be done, just as I used the host headers trick to get WSS installed alongside another web site on port 80; but working out how to do it can be a considerable effort.

VN:F [1.9.18_1163]
Rate this post
Rating: 0.0/10 (0 votes cast)

Related posts:

  1. SharePoint’s secret sauce
  2. Wrestling with Microsoft SharePoint
  3. Word 2010 ugly font in .doc format
  4. Ugly Flash: auto-play audio with no stop button
  5. Importing folders to SharePoint

2 comments to SharePoint – the good, the bad and the ugly

  • I had a real interest in Sharepoint until I started looking into the product a bit more closely. I found parts of it very confusing and and a bit to complex for my liking. Its nice to see here that I am not alone in my thinking. I’m still not sure if its right for me yet. Interesting read. Thanks.

  • I agree that it’s a real pain that SSX doesn’t play well on the same server

    On the complexity for small organisations though…WSS is completely setup for you with SBS so all you have to worry about it using the product

    We use WSS internally and for lots of our clients with great successs.