8 Points to Consider Before You Implement SharePoint

So you're sold on the idea of using SharePoint in your office. When implementing SharePoint, what do you need to consider for a successful implementation? For the best performance and scalability, you need to consider:

1. SharePoint Versions
SharePoint comes in five versions:

Determining which version to purchase can be a little confusing, so I'll summarize the key features of each version.

WSS 3.0 is a free download for users who have Windows Server 2008 or Windows Server 2003. WSS 3.0 is a fully functioning portal. It includes the Standard Site Templates and Web Parts and integration with Microsoft Office 2007. When you install MOSS 2007 (Standard or Enterprise) all the features in WSS 3.0 are included.

Search Server 2008 Express provides enterprise search capabilities for users of WSS 3.0 without requiring them to purchase the full version of MOSS 2007. With Search Server 2008 Express, users can search enterprise content sources and extend search capabilities with iFilters. It includes an improved relevance algorithm that's optimized for enterprise searches. It’s a free download. All the features in Search Server 2008 Express are included with MOSS 2007 (Standard or Enterprise).

Office Forms Server 2007 lets users deploy forms created in Office InfoPath 2007 (available separately) on a SharePoint portal site and centrally manage those forms using Office InfoPath Forms Services. Microsoft released Office Forms Server 2007 to allow users of MOSS 2007 with the Standard CAL to use InfoPath forms without having to purchase MOSS 2007 with the Enterprise CAL. All the features in Office Forms Server 2007 are included in MOSS 2007 with the Enterprise CAL.

MOSS 2007 with the Standard CAL includes everything in WSS 3.0 and Search Server 2008 Express. It also includes Site Directory, Site Manager, Social Networking Web Parts, RSS feeds, user profiles and the Profile Store, audience targeting, Document Management Site Templates, Enterprise Site Templates, integration with Microsoft Information Rights Management, single sign-on (SSO), and other features. It doesn't include the ability to deploy InfoPath forms on the SharePoint portal.

MOSS 2007 with the Enterprise CAL includes everything in MOSS 2007 with the Standard CAL. In addition, it includes business intelligence (BI) features, which let you integrate data from external data sources such as ERP applications and other line of business (LOB) applications. You can integrate any database that's supported via an ADO.NET connection. It includes integrated Data Connection Libraries that centrally store approved connection strings to external data sources. It includes Excel Services, which lets users share BI information in Excel spreadsheets through a browser. With Excel Services, users can display charts, tables, pivot tables, dashboards, and scorecards created in Excel workbooks without any custom development.

For a complete listing of the features in the SharePoint versions, go to Microsoft Office Online. Note that regardless of the SharePoint version, you must store the SharePoint data on a back-end database server. With WSS 3.0, you can use the Windows Internal Database (which is also known as the Microsoft SQL Server 2005 Embedded Edition), but most people use either SQL Server 2008 (Standard or Enterprise Edition) or SQL Server 2005 (Standard or Enterprise Edition).

2. Portal Size
It's often difficult to predict how a SharePoint portal will be used. You might have grand plans for the portal only to find out that it gains little acceptance. Conversely, you might anticipate that it really won't catch on only to find extremely heavy traffic, with the portal struggling to keep up with the demand. In my experience, the best implementations start off small and grow as needed. The development cycle is a little different for portals because most items can be quickly changed and modified. For that reason, I strongly suggest using a prototype approach for any SharePoint project, regardless of the portal's ultimate size. Create a few sites, obtain feedback from users, make the necessary modifications, and repeat.

Some of the most successful implementations I've been involved with are projects that involve some type of catalyst, such as a portal being developed for a new store or a portal for a complex project that involves many players. This type of implementation is highly effective because users are highly motivated to get the maximum benefit out of the portal. It's vital that the SharePoint site becomes the final authority for these types of projects and that all key project players agree to post vital information on the portal. Once the information on the portal reaches a "critical mass" for a project, you're well on your way to successful SharePoint implementation. Once the users realize the potential power of SharePoint, they're more accepting of using SharePoint in other business areas.

One development approach is to develop the all-encompassing SharePoint site that's all things to all end users. In this situation, end users often get overwhelmed with the site and it might not fit their needs. This makes the SharePoint site a very difficult sell to end users, and the portal often goes unused. It's much better to start small and simple. Prototype and grow the portal as necessary.

3. 32 bit vs. 64 bit
Unless you have a compelling reason to install 32-bit SharePoint servers, consider using an x64 platform for both the front-end and back-end database servers. If you plan to integrate BI with your portal, you might need to install a 32-bit server for compatibility. For example, Microsoft Dynamics GP requires a 32-bit SharePoint server to integrate BI into a SharePoint site. However, x64 support is planned in the future.

One primary benefit of an x64 platform is scalability. With the 32-bit platform and the standard edition of Server 2008 or Windows 2003, you can address only 4GB of memory. With an x64 platform and the standard edition of Server 2008 or Windows 2003, you can address 32GB of memory. Scalability is especially important in environments in which you're unsure of how big the portal will grow. The x64 platform has a greater capacity to handle a larger number of users combined with larger portal sites. With the x64 platform, you can somewhat compensate for a slower disk subsystem by adding more memory to the front-end or back-end servers, because this extra memory will cache disk information, providing better overall performance and reducing the load on the disk subsystem.

4. Virtualization
Virtualization lets you run multiple virtual servers on a single hardware host. For a small single front-end/back-end SharePoint server farm, virtualization is a good solution because of reduced hardware costs and better fault tolerance, but what about large installations? Virtualization of large SharePoint farms is also possible. Consider the following items when virtualizing your SharePoint environment:

5. High Availability
A comprehensive discussion of high availability is beyond the scope of this article. However, here are a few guidelines when considering a high-availability solution. If your SharePoint farm must be highly available, consider either Microsoft or VMware clusters. Clusters typically involve shared storage on a SAN with two or more cluster nodes. Clusters are designed to automatically fail over to a different host in the event of a hardware failure. Microsoft clusters are typically single-application clusters, such as a Microsoft Exchange or SQL Server cluster. VMware clusters often are multiple-application clusters, where different applications reside on the same cluster. VMware clusters offer better granular failover capabilities compared to using Microsoft clusters. Clusters are expensive. An iSCSI SAN typically starts at $30,000 and a Fibre Channel SAN starts at $50,000. That's just for the SAN—you still have to purchase the server nodes and software. The easiest way to justify the cost of a cluster is to calculate the cost of downtime.

I typically start considering high-availability solutions for companies that have 250 or more users. I have installed clusters for companies that have fewer users. For example, I had a client that managed a hedge fund that estimated the cost of downtime at $20,000 per minute. Although there were only 30 users in the office, the client decided to implement a cluster because of this high downtime cost.

6. SharePoint Farm Configuration
Many factors must be considered when designing the optimal SharePoint farm configuration for your company's SharePoint portal. Here are a few items to consider when designing your farm:

One of the most common SharePoint farm designs is a single back-end SQL Server database server with a single front-end server. The front-end server manages the areas of central administration, web services, document conversions, Excel calculation services, searches, and incoming email.

If you're using virtualized servers for the SharePoint farm and those servers are on a single virtual server host, it doesn't make sense to break out the different SharePoint server roles on multiple servers, with the exception of separating the database server from the rest of the SharePoint server roles. (This should be done primarily for security reasons.) If you're running virtualized servers for your SharePoint farm and you need high availability and load balancing, make sure you don't have virtualized servers with the same roles running on the same host server. For example, if you want high availability and load balancing for your SharePoint web servers in a virtual environment, make sure that each virtual server is running on a different host. Placing two virtual servers on the same host won't increase fault tolerance because a hardware failure on the host server will cause both virtual servers to go down. In addition, placing two virtual servers on the same host will probably hurt rather than help performance. For comprehensive information about SharePoint farm design considerations, download the free book Planning and Architecture for Office SharePoint Server 2007.

7. Backups
If you're using a SQL Server backup agent, you can somewhat protect a SharePoint installation by either backing up the SQL Server database or dumping the SQL Server database to a file that later gets saved offline. You should backup all the other servers in your SharePoint farm as well. For larger environments that use a SAN, you can take snapshots of the SAN and save them to Just a Bunch of Disks (JBOD) to get around backup time constraints. However, online backups are vulnerable to virus outbreaks and other malware attacks that can potentially leave them useless, so it's important that you copy the snapshot backups to some type of offline media as well.

Most of the major backup software programs now support MOSS 2007-specific backup agents. The advantage of SharePoint-specific backup agents is they offer granular restore and are usually multiserver-farm-aware. Even if you're really good with SQL Server restores, granular restores without a SharePoint-specific backup agent can be tricky. Often I've found that restore requests aren't for the entire SharePoint site but rather for specific subsites or specific content on the portal. This is when these backup agents justify their cost. Although you're somewhat protected with MOSS 2007's Recycle Bin feature, I've run into situations when I still needed to perform a granular restore.

If you have mission-critical data stored on the portal, I suggest purchasing and using backup software that has a MOSS 2007-specific backup agent. I recommend that you either perform a full backup once a week with differential backups during the week or a full daily backup of your SharePoint portal.

8. Disaster Recovery
If you work for a publicly traded company that must be Sarbanes-Oxley (SOX) compliant, it's important to prove that you can recover from a disaster and prove how quickly you can recover. If you've had the unfortunate experience of recovering your SharePoint site after a major hardware failure or disaster, you know it can be challenging. Running a multiserver farm only complicates the restore process. Consider the steps to recover a simple two-server SharePoint farm:

If your SharePoint farm is running virtualized servers, it greatly simplifies the process if you have the virtual server guest images backed up weekly with a traditional backup performed during the week. Consider the following steps using ESX Server as the virtualization platform:

There are also two major advantages when using virtualization for disaster recovery: There's significantly less administrator involvement during the restore process, and restoring to different host hardware doesn't complicate the process. When using virtualization for disaster recovery, you should be able to reduce the recovery time by at least half compared to restoring the servers on bare-metal.

Take the Time
There are many factors to consider when implementing a SharePoint platform that's optimized for your company. Taking the time to address each factor will help ensure your portal performs well and is easily scalable.