Microsoft SharePoint 2010 is a complicated beast, with more knobs and levels than you can shake a stick at. It's no wonder we get some of them wrong
from time to time. Over the past year and a half of installing SharePoint 2010, I've seen quite a few configuration mistakes, mostly at my own hands.
In this article, I'll cover 10 of these errors. I'll explain what the correct configuration is, why it's correct, and how to correct the setting in
your farm. If you make all the changes in this article, you'll have the beginnings of a beautiful farm -- and one less likely to be ridiculed by your
friends and neighbors.
Mistake #1: Scrimping on SharePoint's RAM or Hard Disk Space
If I've seen it once, I've seen it a hundred times: a poor, defenseless SharePoint server working as hard as it can to keep users happy, but having its
hands tied because of limited resources. This situation is usually a casualty of aggressive virtualization. Virtualization itself isn't bad, but it
must be done intelligently and without sacrificing SharePoint's ability to do its job.
If SharePoint finds itself starved for RAM, it starts shutting off functionality so that it can fit into the available space. It also caches less in
the web application pools and recycles those pools more often. Less caching and more recycles result in a degraded end-user experience, as SharePoint
must compile the same ASP.NET code over and over. And no one likes unhappy users, not even their mothers.
The solution to this particular issue is easy: Add RAM. Microsoft has published the hardware requirements for SharePoint 2010 in the TechNet article "Hardware and software requirements (SharePoint Server 2010)." These requirements state that at the very least, each SharePoint 2010 production server should have
8GB of RAM and a C drive with at least 80GB. In many cases, that won't be enough. If your servers are in production, you can watch their memory
utilization to see whether they use the entire 8GB of RAM. If so, they could use more. If your servers are not yet in production, you can use a variety
of load-testing tools to simulate your intended load and see how the servers hold up. For example, you can download the Microsoft Load Testing Kit,
part of the SharePoint Administration Toolkit.
As for your C drive, SharePoint itself doesn't need much space, but Windows does. After all, your server has several years of Windows patches to look
forward to. While you're adding drive space to your machine, consider adding a secondary drive as well. This drive is a great place to store all the
files that you use when you install SharePoint. All the third-party installation files can go there too. You can also have SharePoint put its log and
Search index files on this drive. This approach takes some pressure off the C drive. Happy C drive and happy end users equal a happy SharePoint server
administrator.
Mistake #2: Using Virtualized Microsoft SQL Server
As I said in mistake #1, virtualization isn't bad. But virtualization allows administrators to make mistakes on a much grander scale. Take virtualizing
SQL Server. In the context of SharePoint, this process can be especially painful. The main mistake I see when virtualizing SQL Server is overcommitting
the host, be it through RAM, CPU, or drive space. Because everything in SharePoint is stored in SQL Server, if SQL Server is slow, SharePoint is slow.
The obvious solution is to move SQL Server to a physical box, on which it doesn't need to share resources. Moving SharePoint's SQL Server instance is
easy, thanks to aliases. I've outlined this process, with pictures, at www.toddklindt.com/sqlalias.
If you can't get a physical SQL Server box, then at the very least ensure that your virtualized SQL Server instance has a fighting chance. First, make sure that
its virtual drives aren't thin provisioned. I/O is one of the areas in which virtualized SQL Server struggles the most, and thin-provisioned drives exacerbate
that problem. Also try to put the SQL Server guests' virtual drives on their own spindles on the host. Doing so should improve I/O by preventing SQL
Server from fighting other guests for time with the drives. Finally, you shouldn't allow the virtualization host to overcommit its RAM. If the host must swap
to meet its RAM obligations, then it's slowing down SQL Server.
Brent Ozar has recorded a brilliant video on how best to virtualize SQL. Go get
some wine and pizza, invite your fellow SharePoint admins, dim the lights, and watch that video. You'll learn a lot.