SharePoint Chaos Theory

Posted: March 25, 2008 in MOSS 2007

                Despite its bugs, limitations, and quirks, I truly believe MOSS is one of the best solutions out there for building collaborative and application portals. When properly utilized, it can empower a workforce to work together like they have never before. The key term there being “properly utilized”.  When not properly planned, you can end up with the nastiest rat’s nest and corporate money pit you have ever seen. MOSS is not something you just throw up and go with it needs to be planned out, and documented ahead of time, before you even think of installing it on any server?    The following are some of the critical steps/questions you need to sort though in earnest before embarking on an installation.

1.       What features do you want?

This seems like it would be an easy enough question. However it is not always. It all depends on WHY you want a portal? Are you looking for a corporate dashboard? A document repository? A system to manage workflows? Collaborative team sites? All of the above? None of it? Many clients I have worked with go out and buy licenses without answers to these questions. The problem is you can end up majorly underestimating or overestimating costs without these questions answered? Standard and Enterprise editions for example, are priced very differently. You cannot possibly know which version you want if you don’t know.

2.       Hardware

Hardware is one of the most frustrating components of any MOSS engagement I have been on.  I frequently find myself having to push hard for multiple Web Front ends, application servers, Clustered DBs.  I my opinion, if you are intending your portal to server as your company’s collaborative backbone, document repository, or anything more than just a general curiosity, you cannot afford to cheap out on hardware.  A single server implementation for a production environment is simply unacceptable and if that is all you have a budget for, you really have to accept that you cannot afford a SharePoint  solution. The recovery time for a single server, even with proper backups, can be significant. The smallest production environment I would suggest would be a dual WFE, with a dual SQL 2005 Active/Passive clustered backend.

The DB clustering is the more critical because MOSS is the DB, All your content, configuration (minus whatever has been customized to the web.configs), everything is in the DB. If you have no DB you have no MOSS. Plus rebuilding a WFE is significantly easier than rebuilding a SQL server and reconfiguring all your permissions.

Dual WFE’s are critical for multiple reasons, first of all, sooner or later you will need to patch a server. Given MS’ history with patches, having a single machine is a significant risk in this area. If the patch hoses your box, then your entire portal is gone until you repave and rebuild the web front end.  Also, unless you have the simplest of portals, you will need to configure search (crawling and indexing), MySites, and Profile imports among other things. Throw is workflows, custom web parts, branding, etc and you quickly begin to overwhelm your single WFE. Also, once you have multiple WFEs installed with load balancing, adding additional servers, application or WFE, becomes even easier. It is better to take the hit and pony up the cash for dual WFE’s. BTW, I have many clients running MOSS in virtualized environments successfully. The general way to go is virtualize WFEs and app servers, and leave your SQL boxes are dedicated non-virtualized machines.

3.       Analyze your user base!!

Like any web application, you need to look long and hard at your user base and how you plan on organizing them. I cannot count how frequently a MOSS engagement ends up getting stalled because of this item. So flash forward…you have your dream portal, it is full of content. How do your users access the content? How are they grouped? Do you want a security free for all with users accessing all content? Do you want to end up with massive inconsistent, individual user permissions assignments, and a nasty security model that nobody can figure out or clean up? You need to plan this out ahead of time, then you need to take a long hard look at your AD/LDAP/SQL  auth  model and verify it supports what you want to do. At least 50% of my MOSS engagements have resulted in a total re-architecture of a clients Active Directory structure.

 

A quick note on AD re-architecture, if you are going to do this, then you need to do it right. You need to think enterprise when you do it not just fitting your AD structure into a MOSS shaped hole. You can easily get your AD folks into a homicidal rage when you make 200 AD groups that can only be used within MOSS, then follow up 3 months later with 400 more for your exchange groups, and  300 more for an in house web application.  

4.       Map it out

Crack open Visio, or something like it, and draw out your portal. Draw out your site collection(s), your  portal structure, your MOSS security groups, how they map to your authentication/role providers.  This is critical to sanity check your implementation. With the portal structure mapped out, the security groups defined, customizations like workflows, web parts, etc all defined (at a high level) in a single document, you can get the full picture of what you are putting together. You can identify critical flaws, pain points, etc. Without this, you are shooting in the dark.

5.       Define Governance

Microsoft has some awesome templates for this (http://technet.microsoft.com/en-us/office/sharepointserver/bb507202.aspx ).  You need to know who does what In the implementation. What your support contract is with the user base, who can create sites, who will manage MOSS from central admin, who will serve as site owners. It is also a good idea to put together a MOSS strategy team to help guide where you want to go. The best maintained and utilized MOSS installations I have seen are also the best governed. This is not a coincidence.

6.       Plan the installation

Do not just insert a CD and go for it. You will screw it up. You will have a set of service accounts (if you even make the proper service accounts) that expire 3 months down the road and shut down your SSP. Or your service accounts will not have the correct permissions. Trust me, it will get screwed up and 3-6 months down the road you will end up reinstalling and re-configuring everything or limping along with an unreliable and totally unsecured MOSS farm. Secure farms do not happen by accident or chance. They happen because someone took the time to properly plan them. Do your research, buy the MS Press SharePoint Administrators Companion, or hire a Gold Certified consulting partner to assist.

7.       Know when you are in over your head

The final guideline, know when you are in over your head. To be clear, I work for a MS gold certified partner. Since MOSS was Beta, I have run through dozens of architecture sessions and installs. My company has spent a lot of money to train me and my co-workers as has any gold certified partner. Your average IT department is not going to have the will or budget to train their folks to that extent,  especially when their staff will likely do 1 or 2 production MOSS installations at most. Creating an enterprise portal is not an insignificant task. It can have a huge positive impact on a company or it can have absolutely no positive impact depending on how it is planned and architected.

 

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s