Despite what may seem like a virtual explosion of SharePoint in the enterprise, it has been around since 2001....
However, because of the various architectural changes in the recent version, SharePoint's popularity has taken off. The challenge now is to ensure that it is implemented properly in your environment.
Almost to a fault, SharePoint is easy to install and configure. Using it is pretty easy too. However, because it's so easy, many organizations make "rookie mistakes" when implementing SharePoint. Here is a list of the top mistakes and ways to avoid them.
Rookie mistake # 1: Picking basic vs. advanced installation
When installing SharePoint, many organizations mistakenly take the basic install option because it sounds logical. And it's quite easy -- you can install it with a few mouse clicks.
For more enterprises, however, the advanced option is better.
Always choose the advanced option if:
- You don't want to install everything on the same server. In most cases, the enterprise should have at least a separate SQL Server -- the basic installation doesn't allow you to specify the database server. Further, you must also choose the advanced option if you want a load-balanced set of Web Front End (WFE) servers.
- You want to use full SQL Server -- either new or existing. SharePoint is heavily dependent on SQL Server to store content and configuration. The basic install will install SQL Express, which works for development or very small installations -- like a workgroup -- but it's not suited for departmental or enterprise deployments.
- Fault tolerance is required. Many enterprises wrongly assume that load balancing or highly available environments are for performance. In fact, most often fault tolerance is a higher priority and the real reason to leverage load balancing, RAID or other high-availability solutions. The basic installation does not allow you to configure a highly available environment.
Rookie mistake # 2: Improper use of service accounts and permissions
SharePoint, like many server-based tools, needs to interact both with the server it's installed on and with services that surround it. As such, it requires "service accounts." These are special identities used by SharePoint to communicate with SQL Server, crawl content, add index information on the file system and create worker processes, among other functions.
When installing SharePoint, many organizations incorrectly use generic server accounts like NETWORK SERVICE or SYSTEM. Alternatively, an administrator or equivalent is used. Neither approach is recommended. Instead, consider using a separate domain account for each primary SharePoint service. Each account should be configured with the fewest privileges possible.
Here's a quick list of the accounts, at minimum, that should be created:
- Primary SharePoint service account. This is used for Central Administration and "talking" to SQL Server.
- Search account. There are a few places where search needs a service account. It's acceptable to use one account for all three, but because the search account needs administrative privileges on the Index and WFE servers, you may want to use separate accounts for the different search services. Be aware that the crawling account is also used to access the membership directory, in addition to your content. So you'll want to make sure it has the rights to access that content.
- Application accounts. For each Web application -- think website -- in your environment, you should create a separate identity. This helps create security boundaries between applications and has the added benefit of helping identify which worker process is servicing a given application. For example, in Task Manager, the identity of a process is listed next to the process.
- Shared services account. If installing Microsoft Office SharePoint Server (MOSS), shared services is what controls enterprise search, My Sites and the BDC. It is a separate application like your other SharePoint sites.
Rookie mistake #3: Incorrect drive space allocation
The SharePoint installation process puts everything -- software, indexes, location of custom solutions, logs -- on the primary system drive, and it's often the C drive. In many organizations, however, the C drive is partitioned smaller for just the OS files. As a result, space can run out quickly.
Depending on the role the SharePoint server is playing -- either Web Front End (WFE), search, index or database -- it will have different space requirements. If the server is a search or index server, you'll need at least 25% of your total content storage available for the indexes. On a small C partition, space runs out quickly if you crawl a lot of content. And, keep in mind: If a machine is running SQL Server, everything goes into the database. Every bit of content will be stored as a binary, and the database files and transaction logs will grow rapidly. If versioning is enabled, this expansion will be rapid. In short, be sure to place data files, indexes and other assets related to your SharePoint site on a drive with plenty of space.
Rookie mistake #4: Ignoring disaster recovery situations
Many organizations disregard or dismiss the special nature of SharePoint when developing disaster recovery business continuity plans. SharePoint is more complicated than your average database-driven portal. As such, you need to understand its architecture and make plans for reconstituting your environment.
Although a rookie mistake list could be much longer, this checklist highlights the ones that are made most often. Using this checklist can help Windows managers avoid these common SharePoint implementation errors, which will save time and future headaches. Your situation and needs will vary. Just plan accordingly.
More on SharePoint implementation
- Take control of SharePoint security with authorization techniques
- SharePoint performance demands finely tuned SQL Server, storage
- Want to learn more about Microsoft SharePoint? Sign up for our new SharePoint newsletter and get tips and tricks on implementation, governance and more.
Shawn Shell is the founder of Consejo Inc., a consultancy based in Chicago that specializes in Web-based applications, employees and partner portals, as well as enterprise content management. He has spent more than 19 years in IT, with the last 10 focused on content technologies. Shell is a co-author of Microsoft Content Management Server 2002: A Complete Guide, published by Addison-Wesley, and the lead analyst/author on the CMS Watch SharePoint Report 2008.