The 5 Commandments of SharePoint Deployments

  • Article

At Microsoft, one would think that Best Practices are the Rule of Law. So one would think.

Being young to the team and to the company I see that things are not as they seem. Not as bad as it seems, nor as orderly as it seems. In my former pre-Microsoft life I was SharePoint consultant and saw the same mistakes being made over and over again. It still hasn't changed. ;)

I had published in REDMOND magazine , what are known as the 5 Commandments of SharePoint Deployments. There are 10, but no one would deploy the thing if I revealed the other 5! So, without further ado, I post the 5 Commandments for MOSS (with an eye forward to O14).

 

The 5 Commandments of SharePoint Deployments

A successful SharePoint deployment must be built with a solid understanding of information architecture and the organization's needs. Here are some of the most common things you should take into account before (or as) you design your SharePoint infrastructure.

1. Thou shalt not put all documents into SharePoint. This is a common mistake. SharePoint is a good document repository, but it should not replace your file servers. Keep non-collaborative documents on your file servers and point SharePoint to the file server to use as a content source. Dropping all documents into SharePoint unnecessarily grows your SQL database and makes a backup and restore more cumbersome, especially for a file-level restore. The cry that the File Server was dead, was pre-mature and did not take into account the value proposition of the collaborative nature of SharePoint versus the archival purposes of the file server.

2. Thou shalt put processing power on the Web front-end (WFE)/Query Server. Architects often place the biggest, most powerful piece of hardware at the back-end with SQL. But if that database is dedicated to SharePoint, you are off course -- the "hoss" should be placed at the front-end with the WFE. That's the end that gets busy with crawling content and serving up user requests. For designs that break out the Indexer from the WFE/Query it gets a little trickier. If you are crawling over 500GB of content, put the RAM in the indexer and add a proc to the WFE. For designs that use Enterprise features such as Excel Calculation Services or Business Data Catalog, add more RAM. And then add some more. All on the Front End. For the BDC, make sure that your external data source is tuned correctly for the entities that your application definition specifies. Latency will greatly affect performance probably more than any other single factor.

3. Thou shalt not underestimate cost requirements. There are many costs associated with MOSS. Hardware, software licenses, storage, and Human. Don't worry about overbudgeting MOSS; you won't. Let's take the human factor first. You should invest man-hours to make MOSS work right. Expect to budget 0.5 FTE (Full Time Employee) for every 100 content sources you have. Now, storage costs: Obey the Golden Rule of SharePoint -- for every 1GB of data, set aside 5GB to 6GB of storage capacity somewhere for that data. If you don't adequately size your disk space, you'll be forever adding space at inconvenient times. Hardware costs: Get a SAN. Now. I mean it. Did you just say DAS? You owe me a new keyboard! I am purposely avoiding the licensing issue. I've said enough.

4. Thou shalt not scrimp on user training. What if you built a killer app and no one used it? Fail to train your users, and you'll find out. Develop an internal training program or pay for competent external training, but do not let your investment go down the drain. User adoption is key to a successful deployment. There are a number of competent training companies out there; such as Mindsharp , SharePoint Experts , The Ted Pattison Group , SharePoint Solutions , among others.

5. Thou shalt respect the Master Page. Default.master should be protected and not "monkey'd with" unless you absolutely, positively know what you are doing. Master pages provide the look and feel for all of the pages in your sites. Follow the rule of B. (Back it up first) However, if you do make changes directly to Default.master and you messed it up with changes that you made, try resetting Default.master to the site definition. If that fails, go to your backup.

As I said before, there are another 5, but first ye must crawl before ye run.  

On another note, I will be writing another article for REDMOND magazine soon and speaking at the TechMentor Conference in both San Francisco and Orlando.