Architecting a SharePoint 2010 Deployment : Understanding the Reasons for Deploying Multiple Farms

1/16/2011 3:10:48 PM
A SharePoint farm is fundamentally a collection of SharePoint role servers that provide for the base infrastructure required to house SharePoint sites and provide for other services, such as enterprise search. The farm level is the highest level of SharePoint architecture, providing a distinct operational boundary for a SharePoint environment. Each farm in an environment is a self-encompassing unit made up of one or more servers, such as web role servers, service application role servers, and SharePoint database servers.

In many cases, a single SharePoint farm is not enough to provide for all the needs of an organization. Some deploy multiple SharePoint farms to provide for test environments, farms where development can occur, or farms for extranet users or Internet use. You need to define how many farms are required for an organization when beginning the design process, because the number of farms created can directly reflect on the physical architecture of the servers in a SharePoint environment. Generally speaking, the more farms required, the more hardware is needed, so a full understanding of what can be gained by deploying multiple farms is first required.

Deploying Test Farms

Any production SharePoint environment should have a test environment in which new SharePoint web parts, solutions, service packs, patches, and add-ons can be tested. This applies to all organizations, regardless of size. It is critical to deploy test farms, because many SharePoint add-ons could potentially disrupt or corrupt the formatting or structure of a production environment, and trying to test these new solutions on site collections or different web applications is not enough because the solutions often install directly on the SharePoint servers themselves. If there is an issue, the issue will be reflected in the entire farm.

Because of these reasons, many organizations create a smaller SharePoint farm just for testing. The farm should be similar to the existing environments, with the same add-ons and solutions installed and should ideally include restores of production site collections to make it as similar as possible to the existing production environment. All changes and new products or solutions installed into an environment should subsequently be tested first in this environment.


The SharePoint server or servers used for a test farm or even a production farm do not necessarily need to be installed on physical hardware; many scenarios with SharePoint servers installed on virtual server infrastructure are possible.

Deploying Development Farms

Developers in an organization that makes heavy use of SharePoint often need environments to test new applications, web parts, solutions, and other SharePoint customization. These developers often need a sandbox area where these solutions can be tested, and potentially one with different characteristics from production. These environments are also typically quickly provisioned and deprovisioned, so test environments are not the best location for them.

For these organizations, it may make sense to deploy one or more development farms so that developers have the opportunity to run their tests and develop software for SharePoint independent of the existing production environment. When developed, these applications can first be tested in the test farm and then finally deployed into production. For information on automating the creating of test farms using virtual host management software.

Deploying Extranet or Intranet Farms

Another reason to deploy multiple farms is for security. For security reasons, it is not generally recommended to have an internal SharePoint document management or intranet environment directly accessible from the Internet unless it is secured by an advanced reverse proxy platform such as Microsoft’s Forefront Edge line that includes the Threat Management Gateway or Unified Access Gateway products.

Even for environments properly secured for inbound access, there may be scenarios in which SharePoint content needs to be made accessible by external users, such as in anonymous Internet portal scenarios or for extranet partner scenarios. Because a SharePoint farm requires high connectivity between farms members, it subsequently becomes necessary in these cases to deploy dedicated SharePoint environments in the DMZ of a firewall or in another isolated network.


SharePoint Content Deployment can be used to push site content from one farm to another, for example, when content from an internal farm is pushed to an external extranet farm on a regular basis. The extranet farm remains secure and cannot access content on the internal farm, but users can still access required content that has selectively been chosen for publishing.

Deploying Global or Distributed Multifarm Environments

For environments with multiple geographical locations, it may make sense to deploy multiple farms in different geographical locations. This enables SharePoint content to be consumed locally and is what is recommended in scenarios in which WAN links are not as robust. Consider several key points before deciding where to deploy geographical farms:

  • A single SharePoint farm should not span a WAN link and should ideally be limited to one geographical location. In some organizations, in which the definition of WAN includes at least 1GB of bandwidth with less than 1ms of latency between offices located relatively close to one another, it may be possible to stretch a farm across locations, but this is the only scenario in which this would be supported. If you need to consume content locally, it must be part of a separate farm.

  • There is no native way to do two-way replication of content between farms with SharePoint 2010. However, several third-party companies on the market enable this type of functionality, which can be advantageous in disaster recovery scenarios in which content is replicated to multiple farms.

  • For many organizations, it may make more sense to deploy a single, centralized SharePoint farm in one location rather than to deploy siloed SharePoint farms in multiple locations. Clients access SharePoint using the latency tolerant HTTP/HTTPS protocols, so access to a centralized infrastructure may make sense. It also has the advantages of providing a single URL to access SharePoint and keeps data in one location. Organizations need to decide if the level of service accessing SharePoint across a WAN is sufficient for this to be a possibility.

Planning for Multiple Farms

Consider several key points when designing a SharePoint environment to include multiple farms:

  • All SharePoint server roles, with the exception of the database role, can only be a member of a single farm. You cannot have a SharePoint server reside in more than one farm at a time.

  • A single database server can contain databases from multiple farms, though it is generally recommended to limit the number of content databases on a single SQL instance to no more than 50.

  • If deploying multiple farms on a single SQL server, be sure to use a common naming convention for each farm database so they can be logically organized on the SQL server. For example, naming all databases with the prefix SP_Farm1, SP_Farm2, and so on can help identify which databases belong to which farm.

  • All farm members must have near-full network connectivity (1Gb+ Bandwidth, <1ms latency) to all other farm members, with a large number of open ports with nearly all of them open. This effectively limits scenarios in which firewalls separate farm members, unless all ports are open between hosts.

  • Although not required to have a test environment exactly match production in terms of the number of servers or the type of server roles, it is critical that the web role servers in each environment match each other so that more effective testing can take place.

  •  Understanding the SharePoint Server Roles
  •  Installing Exchange Server 2010 : Installing the Edge Transport Server
  •  Installing Exchange Server 2010 : Installing dedicated server roles
  •  Installing Exchange Server 2010 : Check the Exchange installation
  •  Introducing SharePoint 2010 (part 2)
  •  Introducing SharePoint 2010 (part 1)
  •  Installing Exchange Server 2010 : Unattended setup
  •  Performing a typical Exchange Server 2010 install
  •  Installing the Exchange Server 2010 prerequisites
  •  Outlining Improvements in SharePoint 2010
  •  Understanding the Capabilities of SharePoint 2010
  •  Exchange Server 2010 server roles (part 3) - Edge Transport Server role
  •  Exchange Server 2010 server roles (part 2)
  •  Exchange Server 2010 server roles (part 1) - Mailbox Server role
  •  Exchange Server 2010 and Active Directory
  •  Microsoft Enterprise Library : Non-Formatted Trace Listeners
  •  .NET Micro Framework : Execution Constraints
  •  .NET Micro Framework : Weak Delegates
  •  .NET Micro Framework : Multithreading and Synchronization
  •  Parallel Programming with Microsoft .Net : Dynamic Task Parallelism - An Example
    Top 10
    How To Buy A Hard Drive (Part 2)
    How To Buy A Hard Drive (Part 1)
    Plantronics Backbeat Go, Inno3d Geforce Gt 640, Sony Internet Player With Google Tv, Azio Mech4 Levetron
    TI Computers Ti Deluxe 670 - Fantastic Mix Of Price And Performance
    Apps Round-Up For Mobile Platforms – Oct 2012
    Droid Support - DSLR effects are possible within the Android OS (Part 4)
    Droid Support - Good Games Need More Than Graphics (Part 3)
    Droid Support - Get Your Settings Under Control (Part 2)
    Droid Support - Worried About Security Issues (Part 1)
    1 Month With… Sphero
    Most View
    SAM PowerPC With AmigaOS 4.1
    Microsoft ASP.NET 4 : Dynamic Data Details
    Expert computing advice (Part 1)
    Pocket TV Transfers Normal TV Into Android 4.0 Smart TV
    In Control
    Exchange Server 2007 : Configure the Client Access Server - Enable POP3 and IMAP4
    Exchange Server 2007 : Enable Antispam Configuration
    Collaborating Within an Exchange Server Environment Using Microsoft Office SharePoint Server 2007 : Exploring Basic MOSS Features
    Java EE 6 with GlassFish 3 Application Server : Developing our first JSP
    Sharepoint 2007: Add a Column to a List or Document Library
    Web porn ban: what does it mean?
    Installing Windows Small Business Server 2011 (part 1) - Performing a Clean Windows SBS 2011 Installation
    Delete & Recover Data (Part 1)
    Why Apple Wins? (Part 1)
    Programming the iPhone : UX Anti-Patterns - Sleight of Hand
    SQL Server 2008 : Advanced Stored Procedure Programming and Optimization - Using Extended Stored Procedures
    Designing and Configuring Unified Messaging in Exchange Server 2010 : Unified Messaging Features
    Microsoft ASP.NET 4 : Configuring ASP.NET from IIS
    Kingston Wi-Drive - Rekindling The Wi-Drive
    Microsoft SQL Server 2008 R2 : Hierarchyid Data Type (part 1) - Creating a Hierarchy, Populating the Hierarchy, Querying the Hierarchy