Architecture Planning

Rate this item
(1 Vote)


Architecture Planning"

Plan your farm and network communications before starting actual installation. The first thing to start is designing SharePoint architecture across corporate network. This includes understanding network structure, examining network devices and choosing the right SharePoint topology to fit the existing infrastructure and new requirements.

Examine corporate network

Start from description of the existent network design, location of all applications and system servers. Microsoft Visio 2007 and "Network Diagram" template is a good instrument for this task.

Record the location and information about system servers, like Domain Controllers, File Servers, Mail Servers, Application and other Servers. Dont' forget about network services - firewalls, proxies, and etc. For example, locations of ISA Servers across corporate network - IP address, list of open ports and the administrative user.

The best way to maintain "Network Diagram" document is to update the single diagram that covers topology of all domains and how they are connected. The following diagram demonstrates the Visio document descibing the servers and devices across organization.


This diagram will give a holistic view of the existing topology and ensure quick access to information across different domains.

Examine network devices

All network devices in the topology play a vital role of how SharePoint performs and interacts among different servers. Information about locations and settings of all routers, switches, and accelerators become very importantto plan farm's server locations. For example, location of different WAN and XML accelerators across network affects SharePoint server organization and configuration.

Presence of different network devices affects the connection bandwidth and latency between farm's servers, and thereby, affects the choice of appropriate SharePoint Farm topology. Network Load Balancers (NLB), routers and switches will affect how fast network response, so the farm should be designed with the least impact of these devices.

Refer to the following links for the detailed information about WAN accelerators, NLB and other network devices across SharePoint farms:


Network administrator is a friend

The IT administrator is the person who should participate in farm configuration from the very beginning. This person will be responsible for the configuration of all network servers and devices across corporate network.

Most of the SharePoint Farm topologies cross the bounds of domains and from the very beginning specific protocols and ports must be open. The best way to maintain current situation is to have a separate document, shared with administrator, with the description of protocols and ports to open across network services.

Detailed information about system accounts and list of ports is available in the following articles:


Measure network latency

Network response time is one of the important factors that can affect SharePoint farm design. Ideally, will measure the latency between SharePoint servers and users in order to reorganize servers according the smallest response time.

Network latency is the key point to determine which of the proposed scenarios to implement in the current SharePoint deployment. (Latency is the time required for a packet to travel from one point on a network to another).

Use the Ping tool (ping.exe) to measure latency for:

  • users - from the client computer to the Web server on the server farm;
  • data centres that host servers of the same farm - from a Web server in the remote data centre to the database server in the primary data centre

Do not forget to divide the round-trip result by two, because all measures are one way only, not round-trip.

Compare results to the data below, and adopt environment to have latency lower those values.


Number of users Concurrent users (10%) Central Solution Distributed solution
100-5,000 10-500 Bandwidth:   3+ Mbps (dual T1)


Latency:   < 100 ms

Bandwidth:   1.5 Mbps (T1)


Latency:   <100 ms

10,000 1,000 Bandwidth:     3+ Mbps (dual T1)


Latency:   <250 ms

Bandwidth:   1.5 Mbps (T1)


Latency:   <500 ms

100,000 10,000 Bandwidth:   3+ Mbps (dual T1)


Latency:   < 250 ms

Bandwidth:   1.5 Mbps (T1)


Latency:   <500 ms



The critical bandwidth for any SharePoint farms is 1.5 Mbps (T1) with 500ms latency. Overstepping these values will increase the page-load times dramatically, in 4 times at least. Refer to the diagrams in the "Plan for bandwidth Requirements" document, for more details about the bandwidth and latency results under different conditions.

Available network bandwidth and latency influences geographic deployments significantly. Data transfers across WAN links that span multiple cities, states, provinces, countries, or continents requires really fast lines to provide adequate response time, so design such topologies thoroughly.

More details for bandwidth requirements available in the following article

Become familiar with SharePoint farm communications

Before discussing servers' redundancy and farm topologies let us review farm servers and how they communicate with each other. The following picture from from "Planning an Extranet Environment for Office SharePoint Server" TechNet article illustrates the communication channels within a server farm and which servers handle client's request.


When a user issues a query, the query is sent to a Web server. The Web server communicates with the query server to build a list of results, and then communicates with the computer running Microsoft SQL Server to extend the list of results with summarization text, URLs, and security trimming. In parallel, the Web Server gets page data from SQL Server and renders them on fly. This diagram will help in understanding which roles to use on farm servers.

Plan a baseline topology

Analyse the existing infrastructure and plan a SharePoint topology for redundancy.

The term redundancy is often misinterpreted to be synonymous with availability.
Redundancy refers to the use of multiple servers in a load-balanced environment for any of several purposes, such as to improve farm performance, to scale out to accommodate additional users, and to improve availability.
Availability is a more specialized concept that refers to a multiple-server environment that is designed to accept connections and operate normally even when one or more of the servers in the farm are not operational. Therefore, availability implies redundancy.

There are several different topologies - from three to six servers in farm, which can be used as a baseline. Which one to choose depends on the level of redundancy and available hardware. Not all clients can afford topology with six or ten servers in farm due to budget limitation or data centre capabilities. Finding the compromise between numbers of servers, type of hosting and servers' roles become critical task, because this choice will affect performance and extensibility of the SharePoint farm for several years ahead.

Three Servers Farm

The minimum availability for the farm with few servers can be achieved with "3-servers farm" topology. In the current topology Web and Application Servers locate together on the one box and the database is on another box. The remaining, third, server gives a choice of which server role make redundant - Web server role or the database server role.


The farm with the two Web Servers provides redundancy of the Web and Application roles, improving the overall performance. A drawback of this design is that your data is not redundant (left farm). In other case, farm with two Database Servers (cluster) provides data redundancy, increasing availability of critical data, but users might suffer from temporary loss of access, when Web Server unavailable (right farm).

The "3-servers farm" is one of the most questionable farms in terms of redundancy and performance. This limitation in the number of servers cannot provide redundancy of Query Server and high performance at the same time.

Redundancy can be achieved with Query Roles on both Web App servers. In this case, Database Server is the only place for Index Role, but this will hinder the overall performance. The Index Role is very CPU and HDD consuming role and that is why database servers are not very optimal place for this role. Alternative solution is to assign Index Role to the Web Server with the Query Role, but this will not work effectively, because in this case, index will not be propagated to another Query Server in farm.

If performance is one of the priorities then consider using Query Server and Index Server Roles on different Web Application Servers. This is flexible design in terms of extensibility, because with the new servers in farm changing roles of Index and Query servers is not required.

Interestingly, a TechNet article (, page 26) explains, that a Query Server can't be used with Web Applications server for 3-servers farm. The reality is that, Web App and Query Role together are super common, more common than not (one of the reasons is that Query Server doesn't use Network-Load Balancer - it uses its own algorithm).  What they actually mean in the TechNet article is that having the  Index on database server is not at all a recommended solution.

Four Servers Farm

Additional, forth server will add redundancy either for Data Server or for Web Server. However, it does not help much with performance. Current topology suffers from the same "3-servers farm" drawbacks - no place for Index Server with Query Role redundancy.

Five+ Servers Farm

The most common and highly available server farm topology is "5+ servers farm", the farm with the middle tier server.



This middle tier server solves all issues of three and four servers topology by providing the dedicated tier for Index and Application roles. Additional servers in farm will extend middle tier, by assigning new roles to those servers - Excel Calculation Services Role, and Microsoft Office Project Server 2007 Role.

The following table summarize farm topology:

Farm Servers



3 - 4

Index on WFE with Query on another box


App Roles on WFE

Index on Database, with Query on WFE


App Roles on WFE


App Roles on Middle Tier


Dedicated Index Server on Middle Tier

App Roles on WFE


Dedicated Index Server on Middle Tier


Dedicated Web Server for Crawling, outside NLB


Dedicated Index Server on Middle Tier

App Roles on Middle Tier in NLB


Dedicated Index Server on Middle Tier


To optimize the overall performance of five and more servers SharePoint Farm, configure a dedicated Web Server for crawling content, especially when crawling a server farm that contains more than 500 gigabytes (GB) of content or crawling content over the WAN. To ensure that user requests are not affected by content crawling, remove the dedicated Web server from the network load balancing rotation. This is especially important in global environments in which the off-peak hours of a regional farm (when crawl jobs are likely to be schedule) coincide with the peak hours of the central farm.

Plan extranet topology

Choose the topology based on requirements for external users. This topology will provide a basis of network extensibility for applications servers and communications between them.

The simplest topology is "Edge firewall topology", which is represented by following diagram, from TechNet article.


This topology applicable for the small farms, when there is no need to separate internal services from corporate network and secure communications between server farms. All remote users are separated from farm by ISA server which plays a role of remote proxy.

For the big farms, when security of communications is a priority, the recommended topology is "Back-to-back perimeter topology". This is very flexible and adaptable topology for all network changes.


The main advantage of this topology is that it isolates the server farm in a separate perimeter network. Layers logically separate all servers and communications are under control - any security damages affect only specific layer, not the entire farm. External user access is isolated to the perimeter network and users can be isolated in different AD for remote and corporate access.

There are some other extranet topology variations, but mostly all of them are based on "Back-to-back perimeter topology" with some modification.


Detailed information about farm topologies can be found in the following documents:

  1. Best practices for My Sites:
  2. Best practices for team collaboration sites:
  3. Planning an Extranet Environment for Office SharePoint Server:

Leave a comment

Make sure you enter the (*) required information where indicated. HTML code is not allowed.