SharePoint 2010: Build SharePoint 2010 for Redundancy and Availability

Your SharePoint 2010 deployment can yield many returns—provided you build considerations for high availability and redundancy into your plans.

William Stanek

Few platforms have as much potential for massive returns as SharePoint 2010. When you build your deployment with redundancy and high availability in mind, it’s one of those rare types of investments that will truly deliver. Regardless of the size of your enterprise, there’s something to gain by taking the time to plan your environment carefully.

SharePoint 2010 is different from its predecessors. There may not be an in-placet upgrade from your current environment if it’s SharePoint Portal Server 2003 or if you are running Microsoft Office SharePoint Server (MOSS) 2007 in a 32-bit environment. SharePoint 2010 runs only on 64-bit versions of either Windows Server 2008 or Windows Server 2008 R2. It also requires a SQL Server database running on a 64-bit version of SQL Server 2005, SQL Server 2008 or SQL Server 2008 R2.

That said, you can perform in-place upgrades of an entire server farm on hardware that meets these requirements. You can also migrate from an existing environment to a new environment using a variety of approaches. To aid your upgrade process, you can perform a pre-upgrade check, as shown in Figure 1 and discussed in the TechNet Magazine June 2010 article, “Get Ready to Upgrade to SharePoint 2010.”

Figure 1 Use the Pre-Upgrade Check to test your deployment readiness

Figure 1 Use the Pre-Upgrade Check to test your deployment readiness

As a budget-conscious IT manager, you’ll want to consider these requirements. You’ll also be curious about whether SharePoint 2010 really delivers. Rest assured, SharePoint 2010 brings a wealth of new and enhanced capabilities for social computing, content management, document handling, enterprise search, business intelligence, application development and Web productivity.

SharePoint 2010 also makes major advances in scalability, manageability and governance. Some of the social-computing improvements include tags, ratings, rich profiles, social feedback for navigation, social bookmarks, discovery and filtering. There are also new Web-based collaborative authoring tools and expanded client capabilities.

Client choices now include Office, cross-browser, mobile mode and offline mode using the SharePoint Workspace. Better reporting ensures that the monitoring features can more rapidly identify potential issues. The Business Connectivity Services offer richer data connectivity and read/write capabilities. The asset libraries—the repository for your organization’s documents and media files—can now include millions of objects.

Add in enhanced workflow with Visio and SharePoint Designer, stronger developer tools with Visual Studio 2010 integration, Silverlight integration, a developer dashboard and debugging tools, and there are compelling reasons to move to SharePoint 2010.

So if you haven’t yet considered SharePoint, there’s never been a better time. At the Orlando ITxpo 2010, Gartner Inc. analysts predicted that by 2015, SharePoint will have become as popular a platform for enterprise content apps as the iPhone and iPad are for consumer apps.

No One Size Fits All

SharePoint 2010 is definitely not a one-size-fits-all situation. There are numerous installation options, including a single-server environment with a built-in database, a single-server environment with a SQL Server database and multiple-server environments with multiple tiers.

In a two-tier environment, you install SharePoint server components and database components on separate servers. In this case, the first tier with SharePoint is called the Web (or front-end) tier; the second tier with SQL Server is called the database (or back-end) tier. In a three-tier environment, as shown in Figure 2, you have front-end Web servers with SharePoint, middle-tier application servers and back-end database servers all working together to deliver SharePoint sites and services.

Figure 2 A three-tier SharePoint 2010 server farm

Figure 2 A three-tier SharePoint 2010 server farm

In any of these environments, you need 64-bit hardware, at least four processor cores and at least 8GB of RAM. Both IPv4 and IPv6 are installed and enabled in Windows Server 2008 and Windows Server 2008 R2 by default. When both protocols are enabled, IPv6 has preference. Although SQL Server and SharePoint 2010 also support IPv6, all end-user URLs must be based on DNS names with AAAA records for SharePoint 2010 to work properly.

Browsing to SharePoint URLs that use IPv6 literal addresses is not supported, except for certain admin functions, such as those requiring a literal address format. In that case, you have to enclose the literal address within square brackets as in this example: http://%5B2001:db8:85a3:8d3:1319:8a2e:370:7344%5D.

Server virtualization is also a possibility. Configure your virtual machines (VMs) using Windows Server 2008 Hyper-V technology as part of a SharePoint Server 2010 farm, which you can also use for front-end Web servers, middle-tier application servers and back-end tier database servers. VMs use external networks to communicate with externally located servers and the parent partition. VMs use internal networks to communicate with other VMs on the same physical server and the parent partition, and private networks to communicate only with other VMs on the same physical server.

Architecture: From Macro to Micro

There’s a logical architecture to SharePoint 2010 implementations. It starts with server farms at a macro level and drills down to the sites and pages at a micro level. Server farms provide physical isolation for your content. You can establish different server farms for different asset libraries to meet further isolation requirements. You may also have to create additional server farms to meet performance and scale objectives.

SharePoint 2010 introduces a new services architecture that lets you independently manage and centralize services. There’s a service application resource that helps you customize and share services across sites within a farm, and sometimes across multiple farms. You can also deploy multiple instances of the same service application within a single server farm. The new service applications mean your SharePoint services no longer have to be contained within a Shared Services Provider (SPP). Service applications can include service settings and one or more databases, or just service settings.

The service applications are just one of several logical architecture components. There are also Web applications, which are IIS Web sites SharePoint creates and uses. You can configure Web applications to use just the services needed. You can also extend each Web application to include up to five IIS Web sites, with each site being handled as a zone. Zones are simply different logical paths (URLs) to access the same Web application.

When you create Web applications and services in SharePoint 2010, they’re attached to an application pool that you specify. An application pool is simply a group of URLs served by one or more worker processes. Each application pool has its own worker processes. They can also have a separate identity to help isolate the individual application pools.

You use policy to enforce permissions on all content within a Web application. By default, all content for a Web application is stored in a single content database. You can also separate that content into multiple databases at the site-collection level. While a content database can include one or more site collections, you can’t have a single site collection span multiple databases. Generally speaking, you won’t want more than 100 content databases per Web application.

A site collection is a set of Web sites with the same owner and shared administration settings. Each site collection contains a top-level Web site and most likely one or more sub-sites. A site consists of one or more related Web pages and other items hosted in a site collection. You’ll want to limit the site collections to 50,000 per content database. In practice, having fewer than 10,000 will ensure optimal performance.

Scale out by distributing site collections across multiple database servers. This strategy will increase storage capacity and throughput. You’ll also want to limit the number of sites per site collection to 250,000 in most cases. Limiting the amount to less than 5,000 will simplify backups and upgrades.

The overall complexity of your SharePoint 2010 server environments will ultimately depend on the specific requirements of your organization or a particular project. You can provide different implementations and configurations to meet different needs. For one project, you may want an asset library at the team or department level. For another, you may want a central repository for the entire organization. At the very least, your plan should include several factors:

  • Identify digital asset management roles: Determine the participants and stakeholders.
  • Analyze asset usage: Identify who works with various digital assets, what types of digital assets are involved and how they use the assets.
  • Plan the asset library organization: Determine how many libraries you’ll need, where to create them, how you’ll use them and how to organize them.
  • Plan content types: Determine the types of content you plan to include within a particular library, such as text, images, audio and video.
  • Plan content governance: Determine the appropriate degree of control for each content category and storage location, and the policies you need to apply for auditing, retention and labeling.
  • Plan content workflow: Determine whether and how you plan to use document versioning, checkout and check-in within each library.

You can manage your company’s media assets—like images, audio and video—together or separately from your documents and other types of text files. Generally, you’ll want to use a single- or separate-site collection approach to organize digital assets. With the single-site approach, the content database contains all the site content, including all media assets.

With the separate-site-collection approach, you use different collections for site content and media assets. For example, you’d set up the Site Collection 1 content database for site content and the Site Collection 2 content database for media assets. Separating media files from document files often makes sense. You’ll be able to manage the two types of data separately and scale out more readily.

While you’re considering asset architecture at the macro level, you’ll also want to think about general configuration, especially:

  • Bit Rate Throttling: This lets you meter the download speeds of media files and data to ensure overall performance isn’t degraded. You should always use bit rate throttling when an asset library includes large files like audio and video. This is a feature of IIS 7, so you’ll have to have it installed, enabled and configured in IIS 7 on every front-end Web server.
  • Disk-Based Binary Large Object (BLOB) Cache: This controls BLOB caching, including frequently used images, audio, video and other files used to display Web pages, such as .js and .css files. You should use a BLOB cache if your environment has asset libraries. The BLOB cache is enabled in IIS 7 and stored on every front-end Web server. You’ll have to configure your Web servers with sufficient storage capacity for caching. You may also want to consider using Remote Blob Storage (RBS). Removing the BLOBs from the database makes it easier to scale large volumes of content (see Figure 3).
  • Maximum File Upload Size: This controls the maximum file size users can upload to a server. This is configured for every Web application on a server that hosts Central Administration. You should adjust this feature based on the type and general size of files you’ll need to upload to asset libraries. Configure database servers with sufficient storage to accommodate those types of files.

Figure 3 Separating BLOB data from other content

Figure 3 Separating BLOB data from other content

Regardless of whether you have single-server environments, multiserver farms, virtual servers or unique implementations thereof throughout the enterprise, business-continuity planning is a must. Business-continuity planning involves a focus on protecting your company’s digital assets using redundancy and availability mechanisms where appropriate.

Protect That Content

It’s your job to build outsized content protection into every SharePoint 2010 environment. It starts with recycle bins and version controls. SharePoint 2010 supports two types of recycle bins:

  • User Recycle Bins (first-stage recycle bins)
  • Site Collection Recycle Bins (second-stage recycle bins)

When you enable recycle bins, you can delete items in two stages (see Figure 4). The first stage is a recycle bin. This can restore files, list items, lists, document libraries and other items users have deleted. When a user deletes an item by sending it to the recycle bin, it’s held there until it’s deleted,  expired or is restored. The recycle bin is at the site level and available to users who have Contribute, Design or Full Control permissions on a site. Either users or site collection administrators can recover a deleted item by restoring it from the recycle bin.

Figure 4 Two-stage recycle bins in SharePoint 2010

Figure 4 Two-stage recycle bins in SharePoint 2010

Both users and site collection administrators can delete an item from the recycle bin. From there, the deleted item is sent to the site collection recycle bin. This is located at the site collection administrator level and available only to site administrators.

By default, deleted items have a total retention time of 30 days. This is important to note: An item deleted from the user recycle bin after 20 days, then sent to a site collection recycle bin, would only have 10 more days before it would be automatically—and permanently—deleted.

The site collection administrator controls the expiration of deleted items by setting the time limit for items held in the recycle bins. Administrators can manually delete items earlier if a site-collection recycle bin reaches its size limit.

You can also build in redundancy by using versioning as part of content control, which includes content-approval permissions and document checkout and check-in to better control how and when document versions are created. Default document controls are specific to a particular asset library and depend on the site-collection template applied to that asset library. SharePoint 2010 has three versioning options:

  • No Versioning: Version controls are disabled and there are no previous versions of documents created. As a result, no document history is retained.
  • Create Major Versions: Each time a document is saved, the previous version is retained. Administrators control the number of previous versions to keep. Users with permissions in the asset library will be able to view the document and its major versions.
  • Create Major and Minor (Draft) Versions: Documents have major versions you can consider as published versions. Consider minor versions as draft versions. Major versions end in .0 and minor versions end in non-zero extensions, such as .1, .2, .3 and so on. Each time someone saves a document, SharePoint also saves previous major and minor versions. Any user with read permissions can view major versions of documents. Generally, any user with edit permissions can view and work with minor versions of documents.

Better Backup and Recovery

Your content-protection plan should include availability, backup and recovery strategies. Those strategies will vary depending on your business requirements, the types of digital assets involved and their relative value.

For high availability, you’ll want to use a collection of servers that help mitigate the effects of both planned downtime such as system updates, and unexpected downtime such as outages. You can add Web servers and application servers to a farm to scale out. This will help ensure availability of services and applications.

To improve back-end database availability, you’ll have to dig into your toolbox for database-clustering and database-mirroring tools. Database clustering provides availability support using failover clusters. The clustered servers (called nodes) are connected by physical cables and by software.

If one node fails, another node begins to provide services. This process is called failover, and ensures users experience a minimum number of disruptions in services and connectivity to back-end databases. Failover clusters provide improved availability for applications and services that require high availability, scalability and reliability.

Database mirroring provides availability support by sending transactions from a principal database to a “mirror,” or duplicate database. SharePoint 2010 uses a “high-safety mode with automatic failover” configuration for mirroring. This involves a principal, a mirror and a witness. The witness server lets SQL Server automatically failover from the principal server to the mirror server within a few seconds of failure. Mirroring provides redundancy for your SharePoint content and configuration databases.

For backup and recovery, first decide what you want to protect. Use the SharePoint 2010 Products backup and recovery planning workbook to help you develop a plan. SharePoint backups, coupled with database backups, will protect most of your SharePoint infrastructure.

You can use farm-level and database-level backup and restore for site collection recovery if a single site collection is stored in a database. You can also use those backup levels with unattached database recovery to restore site collections, sites, lists and configurations. Farm-level and database-level backup and restores back up and recover digital assets stored in RBS stores, along with other content (as long as the RBS provider has this capability).

These backups won’t include certain types of customizations, however. You have to back up changes to web.config files not made with Central Administration at the file-system level. You must also back up changes to IIS configurations not set through SharePoint at the IIS/OS level. You can recover the Central Administration content database and the configuration database for a SharePoint farm, but only as part of a full-farm recovery to the same farm with the same servers.

With service applications, remember that you can’t restore a complete service application by restoring only the related databases. You must restore the databases and then re-provision the service application. Finally, you’ll have to back up and recover SQL Server Reporting Services databases separately from SharePoint backup and recovery. Use the SQL Server tools for those tasks.

This is how you can build your SharePoint Server environment for redundancy and availability. When it comes to SharePoint 2010, no one size fits all and there are many logical components that you must consider when designing the physical architecture. You also must consider how to optimally configure your SharePoint environment to protect your digital assets.

Will SharePoint really become as popular a platform for enterprise content apps as the iPhone and iPad are for consumer apps? I guess we’ll have to wait and see.

Joshua Hoffman
William R. Stanek( is a leading technology expert, an instructional trainer, and the award-winning author of more than 100 books. Current and forthcoming books include “Active Directory Administrator’s Pocket Consultant” (Microsoft Press, 2009), “Windows Group Policy Administrator’s Pocket Consultant” (Microsoft Press, 2009), “Microsoft SQL Server 2008 Administrator’s Pocket Consultant 2nd Edition” (Microsoft Press, 2010), “Windows 7: The Definitive Guide” (O’Reilly Media, 2009), “Windows Server 2008 Inside Out” (Microsoft Press, 2008), “Windows PowerShell 2.0 Administrator’s Pocket Consultant” (Microsoft Press, 2009), “Windows 7 Administrator’s Pocket Consultant” (Microsoft Press, 2009) and “Windows Server 2008 Administrator’s Pocket Consultant, 2nd Edition” (Microsoft Press, 2009). Follow Stanek on Twitter at


Related Content