As a SharePoint consultant, I’ve come across many different architectures and designs of SharePoint portals. When I am asked to assist in the design of a brand new architecture or assist in the redesign of their current infrastructure, I try to assess my clients’ understanding of their design needs. I more often than not come across things where, if implemented originally, may cause pain at a later time. Here are some of the most common things that I see that you should take into account before (or as) you design your SharePoint infrastructure.
1. Do not put all documents into SharePoint. This is a common mistake. SharePoint can be a good document repository, but it should not replace your file servers for documents that are collaborative in nature. A better design would be to keep non-collaborative documents on your file servers and point SharePoint to the file server as a content source. Putting all your documents into SharePoint unnecessarily grows your SQL database and makes a backup and restore more cumbersome. This becomes and issue when you need a file level restore. There are great products to help mitigate this, but if you only implement out of the box features—save yourself the potential headache.
2. Put the processing power on the WFEs, not the SQL back end. Another misconception that plagues architects is the issue of how much hardware, its specifications and its location. The most common error made is placing the biggest, most powerful piece of hardware at the back end with SQL. If the SQL database is dedicated to SharePoint, that is nothing else will be utilizing it, the placement of the power is misdirected. The “hoss” should be placed at the front end with the WFE. That is the end that is doing the crawling, the end that is serving up user requests and the server most utilized. Performance is a huge consideration for any application and SharePoint is no exception. The correct placement of power is critical to get every ounce of performance out of this application.
3. Don’t underestimate the amount of space needed. If you plan to deploy SharePoint you need to understand that more is what you need. More hardware, more people, and more disk space. Can you spell SAN? You’d better. A typical ratio to use would be 5 or 6 to 1, that is—for every 1 GB of data, you will need 5 or 6 GB of free space. Yes, I’m not kidding. If you don’t adequately size your disk space you will be forever adding space at inconvenient times .
4. End user training is crucial for a deployment of SharePoint to work. Imagine this: You spend all the time and money your company has to deploy this killer app and no one wants to use it because they don’t understand how it works. Spend the time to develop an internal training program for end users or spend the money on competent external training. Don’t let your investment go down the drain.
5. If search is the reason (or deciding factor) you chose SharePoint, making sure the result sets are accurate and informative can be a time consuming effort if your implementation has more than 100 content sources. A good measure to use is 0.5 FTE (Full Time Employee) for every 100 content sources. That is to say, if you point your SharePoint server to crawl 100 different places, one-half of someone’s day will spent on ensuring that what is crawled is useful, that errors are resolved, that the content sources are being correctly crawled, that filters are correctly working, etc.