8 Points to Consider Before You Implement SharePoint

Executive Summary: For the best performance and scalability, you need to consider eight factors before you implement Microsoft SharePoint in your organization.

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. Which Microsoft SharePoint version will best meet your needs
2. The size of your first portal
3. Whether you want to use a 32-bit or 64-bit platform
4. Whether you want to use virtualization
5. Whether you need a high-availability solution
6. How you want to configure your Microsoft SharePoint farm
7. How you want to back up your Microsoft SharePoint platform
8. How you want to restore your Microsoft SharePoint platform if a disaster strikes

1. SharePoint Versions
SharePoint comes in five versions:

• Windows SharePoint Services 3.0 (WSS 3.0)
• Microsoft Search Server 2008 Express
• Microsoft Office Forms Server 2007
• Microsoft Office SharePoint Server 2007 (MOSS 2007) with the Standard CAL
• MOSS 2007 with the Enterprise CAL or for Internet Sites

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:

• Virtualization platform. Although you can use free virtualization products that run on top of a general purpose OS (e.g., VMware Server, Microsoft Virtual Server 2005), I recommend that you use a hypervisor (e.g., VMware ESX Server, Microsoft Hyper-V) for the best performance. In my experience, hypervisors' performance is significantly better than that of free virtualization products. In addition, with hypervisors, you get significantly higher (sometimes double) consolidation rates of virtual servers per hardware host. You take a minimal performance hit (around 4 percent) for running a virtual machine on a hypervisor versus running that same machine on dedicated hardware.
• Load balancing. If you plan to load balance front-end servers in a virtual environment, make sure that the front-end servers are on different hosts. If you put the front-end servers on the same host, you'll probably take a performance hit rather than experience a performance gain and you won't gain any fault tolerance.
• Memory limitations. Both ESX Server and Hyper-V let you allocate up to 64GB of memory to a virtual server guest. Unless you're running an extremely large database server, this should be enough memory for most SharePoint database servers. Free products such as VMware Server and Virtual Server 2005 have a maximum of 3.8GB of memory per virtual server guest, which can be limiting even for a small SharePoint farm.
• Anticipated CPU load. SharePoint farm servers have a potential for heavy CPU loads from several sources: SSL sessions, virus scanning, stored procedures, and farm crawling. Some virtualization platforms like ESX Server let you reserve a number of CPU cycles for a specific virtual server guest. If you anticipate heavy SSL traffic and require load balancing on your front-end servers, consider using a dedicated SSL accelerator such as an F5 Network BIG-IP appliance to reduce the CPU load on your front-end servers. In a virtual world, don't rely on additional virtual CPUs to increase performance. Increasing the number of CPUs from one to four on a virtual server guest will yield marginal gains of approximately 10 percent. Hypervisors do a pretty good job of allocating resources to the host's CPUs. In general, you'll get better performance by reserving CPU cycles for a virtual server guest rather than allocating more CPUs to a guest.
• Snapshots. One nice feature of ESX Server and Hyper-V is the ability to take virtual guest snapshots. You can take snapshots of the SharePoint server farm before any major changes (e.g., service pack installation, major site upgrade) to the portal. If anything goes wrong when the changes are being implemented, you can revert back to the state of the farm before the changes. If everything goes smoothly, you can incorporate the changes into the virtual server. Snapshots typically take less than a minute to complete, making them significantly faster than even an incremental backup. Be aware that snapshots can quickly eat up space on the host. Taking a snapshot of a virtual server guest creates a delta file that records all the changes to the virtual server guest. When big changes are made to a virtual server guest that has a snapshot, it's not uncommon to see the delta file grow larger than the original virtual server disk file. For that reason, use snapshots sparingly and make sure you have plenty of free disk space available on your virtual server host.
• x64 guest support. If you plan to run x64 virtual server guests, you need to verify two factors: The virtualization platform must support x64 guests (ESX Server and Hyper-v have x64 guest support), and the virtual server host's BIOS and CPU must be capable of x64 virtualization.
• Disaster recovery. If you've been unfortunate enough to go through the task of recovering a SharePoint farm, you know that it's difficult and painful, even with good backups. If your SharePoint farm is running on a virtualized platform and you have image backups of your virtual servers, the recovery process is significantly simplified. I suggest that you take image backups of your virtual server guest at least once a week along with performing traditional full or differential backups during the week. Virtual server image backups involve taking a snapshot of the virtual server guest, backing up the virtual server disk file, then deleting the snapshot. If you have the virtual server disk images backed up, the recovery process is significantly simplified. To restore the virtual server on a different host, you just need to install the hypervisor on the new hardware, install the backup software, install the backup agent on the virtual server host, and restore the virtual server disk images. After you start the virtual server guests, you might need to restore the latest full or differential backup. Because virtualization creates a hardware-agnostic platform, you can restore these virtual server guest images on a different virtual server host running the same virtualization platform without any problems. If you have x64 virtual server guests, make sure your new host is capable of hosting x64 virtual server guests.

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:

• Internet access to the portal. What is the anticipated traffic from the Internet? Make sure to take into account not only your Internet connection line speed but also the current peak and average utilization of your Internet connection. If you anticipate heavy usage from the Internet, you might need to increase your Internet bandwidth. When accessing a SharePoint site from the Internet, I consider SSL connection mandatory. Multiple SSL sessions can place a significant load on the SharePoint web server. If you anticipate more than 50 concurrent sessions, consider using a dedicated SSL load-balancing appliance with two or more front-end servers for fault tolerance. This appliance will reduce the CPU load on the web server and often do a much better job of load balancing compared to Microsoft's Network Load Balancing (NLB) because the appliance will take into account actual traffic volume rather than connection counts. SSL load-balancing appliances usually provide an SSL proxy and packet inspection of the SSL traffic, greatly increasing the security on the SharePoint site. If the portal will be accessed primary from the Internet, consider placing the SharePoint farm in a co-location facility or hosted SharePoint services facility.
• Dedicated servers for SharePoint roles. If you anticipate heavy usage of the portal for searches, web services, document conversions, or Excel calculation services, consider dedicating a server to each server role in which you're expecting heavy usage. For fault tolerance, consider using two or more servers for each role for high availability.
• Database servers. If your site is extremely large, you might want to distribute your logical SharePoint site across two or more database servers.

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:

1. Purchase new hardware.
2. Install Server 2008 or Windows 2003 on the database server.
3. Install the backup software.
4. Catalog the tape on the backup server.
5. Install the backup agent on the database server.
6. Restore the programs (including SQL Server) on the database server.
7. Restore the databases on the database server.
8. Install Server 2008 or Windows 2003 on the front-end server.
9. Install the backup agent on the front-end server.
10. Restore SharePoint on the front-end server.
11. 11. Test.

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:

1. Purchase new hardware.
2. Install ESX Server on the host server.
3. Install the backup software.
4. Catalog the tape on the backup server.
5. Install the backup agent on the ESX Server host.
6. Restore the SharePoint farm servers on the ESX Server host and start them.
7. If necessary, restore the latest full or differential backup on the servers. Optionally, restore the latest full or differential backup on the database server.
8. Test.

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.