Two Types of SharePoint/MOSS Environments

Welcome to all the new readers. I guess getting Brilled is somewhat similar to getting Slashdotted, if the 5000% increase in traffic is any indication. Thanks, Ed.
I’m mildly amused that when I start to border on ranting, the level of attention increases, but I won’t worry about that today. I have other things on my mind.

Now, this is all based off circumstantial evidence, not hard research, but given that caveat…

There seem to be two different ways organizations are approaching SharePoint, and they are diametrically opposed to each other:

Method 1: Install a server, see what it can do, use it for small apps, and expand its function and the scope of the environment based on demand.

Method 2: Assume that demand will be huge, and engineer a large, complex architecture to support that assumed long-term demand. (We did this.)

While I appreciate the strategic foresight of method 2, and the desire to not be constantly re-working your infrastructure, I have yet to talk to someone who went that route that actually has been successful. Up and running, certainly, but successful? Seems rare. More often, the end users are happy with the platform, but there are internal teams like mine pulling their hair out. Or maybe that does qualify as success, if you have the right perspective.

In any case, folks going with Method 1 seem to be doing just fine. They are getting their feet wet with small stuff, learning the technology on the fly, as needed, and letting the growth of their environment march right alongside the growth of their skillset.

Mistakes are made under both methods, but a small mistake in a large, complex environment, especially if identified after the platform has experienced immense growth into your organizations production systems, can be a real nightmare to fix. I know we’re suffering the pain of mistakes made in the planning phases that didn’t show themselves until 6 months later. And of course, politically, it is unwise to say that the consultants for whom we paid a couple million dollars just plain screwed up. So I won’t say that.

And maybe I’m just looking at the greener grass on the other side of the fence. But seeing as our environment runs about 4 brochure-ware sites, front-ends a handful of custom .NET apps, and runs a few dozen each of lists, doc libraries, and discussions…
I’m just not seeing why we couldn’t have gone with method #1, saved millions of dollars, had a simpler infrastructure, taken less IT resources to support it all, and sure, maybe added a 2nd server if needed.

So as a message to anyone else out there, when planning a new SharePoint deployment, KISS.

Status Update

Well, I finally got a day off from the disaster. Other team members are taking over from here, pretty much. At least over the weekend.

One nasty problem is still under investigation, but we’ve resolved or at least identified the causes and fixes for the rest of the problems.
A few lessons learned:

1) Have your server up to speed before setting up SharePoint. Be sure your patch levels are appropriate, and match on all servers.

2) The SmartPart is a cool little web part. BUT — don’t mix versions. Controls that work fine in older versions might not load properly in newer versions. Root cause unknown, but as it is an open-source thing, I’ll let the authors worry about it. As a consumer, just pick a version and stick with it.

3) .NET Applications are more stable when left on the file system, with their own IIS App Pool. Pulling the aspx pages into SharePoint seemed like a good idea at the time.  But not anymore.

4) Take notes when you set things up. We have a few web services and Search scopes that we need to recreate. If only we remembered exactly how they were configured…  Imagine that. Documentation would have been useful? Who would have guessed?