Intranet SharePoint 2010 Architecture

mountainromeInternet and Web Development

Oct 31, 2013 (4 years and 8 months ago)


Intranet SharePoint 2010 Architecture


The Intranet is (in SharePoint 2010 terms) relatively small. The content to be served is not particularly
large, nor are is the estimated number of requests per day to be serviced “large”.

That said,

there is an identified business requirement for “high availability”, based on the presumption
that since the Intranet will be leveraged by users to link to systems that are “business critical”, the portal
landing page is also deemed business critical.


this business requirement for high availability extends to the Intranet, the number of servers in the
system will typically double. This should allow the system to continue to provide services in the case of
many different causes for outage (planned or ot
herwise). No consideration has been made for other
components of the

networking infrastructure which may also need to handle outages
(planned or otherwise), and allow users to connect to the Intranet. This could include AD domain
firewalls, switches, etc.

Business Requirements

The following have been identified as business requirements that will drive the recommended topology,
and hardware for the solution:

User Base

Users of the new corporate intranet will consist of approximatel
y 7,000

employees who will
be accessing the site through wired/wireless Ethernet and high speed remote or dial up VPN
connections. The typical user load on the site consists of document downloads and searches at a rate of
approximately 10,000 hits

Computer usage by

employees can be broken down as follows:

Desktop users

approximately 2000.

Laptop users

approximately 3000.

Tablet users

approximately 700.

There are some employees who do not use computers at all.


has employ
ees and offices all over the Province of Ontario. Approximately 50% of these are in
the Greater Toronto Area (GTA).


technology infrastructure is set up in a centralized fashion based in the GTA.

What is the expected user concurrency is unknow

the system needs to handle spikes at start of day
when everyone opens it as the default homepage. This may be as many as 1500 users at one time. Many
of the links expected to be on the landing page are for resources outside the Intranet.


The intranet will use the existing Active Directory database to authenticate users and establish user
permissions within the site.


Estimated s
ize of content is about 9Gb. This does not include SUN or Team

ite docs. Average document
size is estim
ated at 5MB per content (this is the smaller of the estimated range of 5MB to 20MB).


is expected to grow at less than 2GB per year.

The recommended architecture will support a number of team sites, as well as SharePoint user My Sites.
Team sites sh
ould be carefully planned based on size and expected growth, as they may require more
than one content database dedicated to storing a group of team sites (or even a single team site, if
size/security warrants it).

Note that the size and number of team
sites and My Sites does not have a direct correlation to the
number of servers required in the SharePoint farm; server topology is more a factor of expected user
concurrency, type of usage, and desired availability & distribution of services. As My Site an
d team site
user adoption ramps up though (and these users upload more and more content), adequate storage
capacity will need to be available to accommodate the subsequent SQL database growth. Accordingly, if
user concurrency levels demand additional proce
ssing power on the Web Front
End tier, the design can
easily accommodate additional WFE servers to handle the increased load.

There is no requirement for crawling (searching) external content.


There is no requirement for SSL
, nor stated requiremen
ts for encryption between SharePoint farm


There is a requirement for “high availability” of the system. Specific cases of failure are not specified.
The need for system high availability exists not because of the business critical

nature of content hosted
in the Intranet, but rather because the Intranet will provide a central “landing page”, with links to the
services that are deemed business critical.

“High availability” has not been defined, but is assumed to be the ability of t
he Intranet to service
requests for the “landing page” in the case of unplanned outages (such as those caused by hardware or
some types of software failure), and most forms of planned outages (due to required updates or
maintenance to components).

for users to perform searches on content, or ability of the system to crawl and index newly added
content are not considered to be services that need to be highly available, nor are services related to
user profile synchronization.

Services / Service Appl
ications Required

The farm will likely need to have the following services installed. There may be others added to this list,
depending on present or future business needs:



Application Registry Service


Business Data Connectivity


Lotus Notes Connector


Managed Metadata Service


Search Service Application


Secure Store Service


State Service


Usage and Health data collection


User Profile Service Application


Web Analytics Service Application


Word Automation Services


SharePoint Server Search (AKA Enterprise Search), indexing and query roles

User Profile service (including user profile synchronization)

Managed Metadata

Usage and Health Data Collection

Web Analytics

Planning for


The Intranet web application will not be protected by SSL.

The Central Admin web site will be protected by SSL, but this can use a self
signed certificate. This won’t
provide mutual authentication, but will provide encryption. The limit
ed number of users of the Central
Admin facility will need to accept the self
signed certificate to access the Central Admin site. This set of
users will typically be restricted to a small set of SharePoint administrators.


has its own certifica
te authority that can issue a trusted certificate, or chooses to obtain a
third party certificate, one can be installed in order to avoid the “invalid certificate” warning for users of
the Central Admin site.

There is no known specific business requirement

for encrypting traffic between the web servers and the
database server, nor a specific requirement to encrypt data on the database server. Technologies that
can enable these types of encryption will therefore not be enabled. Note that these technologies
ntroduce additional overhead to the network and servers.

Note that authentication mechanisms using Windows Integrated Authentication (including Kerberos) are
by nature encrypted

no user credentials will be sent in clear text over the wire.

Service Accoun

Least privileged accounts will be used for the environment, in accordance with best practices. This
requires a number of AD accounts to be created in the environment.

The following Active Directory accounts are required for the solution, along with reco
mmended account
names. None of the accounts require “administrative” privileges across the domain, but some will
require local administrative privileges on servers in the farm.

Short Description

Recommend Account Name (s)

SQL Server service account


Setup user account


Server farm account


Generalapplication pool


Farm service account


SharePoint Server Search
service account


Default content access


Web application service
account for intranet web


Intranet Site Collection Admin


Profile import account


SharePoint Foundation Search
service account


Web Application service
account for My Sites


Cache Super User Account


Cache Super Reader Account


Planning for Web

There will be a single web application for hosting the Intranet application. This web application can also
host all Team Sites, in either a single or multiple site collections and content databases (based on
estimated content size). The reason

for multiple site collections & databases center are mainly centered
on two factors: security and expected content growth in GB. Site collections can be used for security
isolation in the sense that owners from one site collection can be distinct and prot
ected from owners in
another collection. Finally, site growth can be planned and controlled on a per
collection basis
(using quotas), site collections can be limited to one per database, and can be backed up or migrated

A separate Web ap
plication for Central Admin and another web application for the My Sites host site
will also be required. This is a general requirement for SharePoint, and not part of the solution; per se.
My Sites can all reside in a single content database, or be split
into several databases. Since each
individual My Site is actually a site collection itself, the My Site grouping into multiple content databases
strategy is almost purely one of expected content growth.

URLs for these web applications have not been identif
ied in this document.

Planning for Services and Service Applications

A SharePoint 2010 farm can be configured with a number of Services and Service Applications,
depending on your requirements and the functionality you would like to make available.

Some of the available
service applications and
services in SharePoint 2010
, Standard Edition

Service Application or Instance


Application Discovery and Load Balancer
Service Application

Automatically provisioned on SharePoint 2010 farms.

Business Data Connectivity Service

Provides access to line of business systems data.

Business Data Connectivity Service

Managed Metadata Service

Manages taxonomy hierarchies, keywords and social tagging
infrastructure, and publish content
types across site

Managed Metadata Web Service

Search Service Application

Crawls content, produces index partitions, and serves search

SharePoint Server Search

Search Query and Site Settings Service

Secure Store Service

Provides single sign
on authentication to access multiple
applications or services.

Secure Store Service

SharePoint Foundation Search

In SharePoint Server deployments, this service is only used
to search online Help.

Usage and Health Data
Service Application

Collects and returns data on site usage, performance and

User Profile Service Application

Adds support for My Site Web sites and user profile
synchronization, plus profile pages, social tagging and other
computing features.

User Profile Service

User Profile Synchronization Service

Web Analytics Service Application

Provides web analytics and reporting.

Web Analytics Data Processing Service

Web Analytics Web Service

Central Administration

service runs the Central Administration site

Claims to Windows Token Service

The Claims to Windows Token Service (C2WTS) is a
component of the Windows Identity Foundation (WIF) which
is responsible for converting user claim tokens to windows

Microsoft SharePoint Foundation
Sandboxed Code Service

This service runs code deployed as part of a sandboxed
solution in a remote, rights
restricted process and measures
the server resources used during execution against a site
scoped, daily qu
ota. Only required if running
custom code in an isolated fashion.

Microsoft SharePoint Foundation
Subscription Settings Service

Provides multi
tenant functionality for service applications.
Tracks subscription IDs and settings for services that are
ed in partitioned mode. Deployed through Windows
PowerShell only.

Start this service if you have deployed service applications in
multitenant mode or if the farm includes sites using site
subscriptions. This service stores settings and configuration
data f
or tenants in a multitenant environment. After it is
started, Web applications consume this service

Profile Services will be configured to synchronize user profile information from Active Directory.

Planning for Authentication

All users
are expected to be members of the domain; as such Windows Integrated Authentication will be
used for all web applications. For performance reasons, it is recommended to use Kerberos
authentication, instead of NTLM.

This will require setting Service Princip
al Names (SPNs) for the hostnames selected for the web

It may also require having a separate zone configured for the search crawler, which will be configured to
use NTLM authentication.

The Central Administration web site by default is config
ured to use NTLM, and since performance
requirements and load are considerably less than a site that serves user content, it can remain in this

Planning for High Availability

As discussed earlier, high availability for user access to the sy
stem is a requirement.

This demands the following:

Making Web Front End servers highly available to respond to client requests (including search

Making database services highly available to SharePoint

Note that there is no requirement for HA for
crawling content, or for searching content. However having
all WFE servers host the Query role will effectively provide a degree of HA for user
initiated searches.

This also requires separation of the farm into (at least) two tiers, with SharePoint servers

residing in one
tier, and database servers in a second tier. This therefore precludes a single
server deployment (should
such a configuration provide enough capacity to meet other business requirements).

HA for Web Front End servers

At least 2 servers
operating as Web Front End servers, load
balanced using a suitable load balancing

The specific load balancing technology can be either:

An external “hardware
based” load balancer, external to the SharePoint WFE servers. If

has such a d
evice that can be used (for example, it is connected to the appropriate
network(s), and has capacity to handle additional load, this can be used. If not, a net new one
can be obtained.

Windows Network Load balancing. This is software based load balancing,

and is a feature of the
Windows Server OS.

The solution will work with either.

HA for Application Servers

2 servers hosting SharePoint 2010 end
user services and roles such as Search Indexing and User Profile

HA for Central Administration / User

Profile Sync

Since core administrative functions are typically only performed by a very limited group of
administrators, there is not normally a requirement for high availability in the Central Administration
web application. Further, thanks to the ShareP
oint storage design that holds all configuration data and
admin content in SQL, it is quite easy to re
provision Central Administration on any number of additional
servers in the farm (even if the main Central Admin server fails). This, combined with the f
act that we
can opt to initially provision Central Admin on the app servers as well, means that implementing a
classic load
balanced scenario to host Central Admin is not necessary.

The User Profile Synchronization service is only supported to run on a sin
gle server in a SharePoint 2010
farm, therefore this role can and should reside on a single server only. Similarly to Central Admin, this
service can be re
provisioned on another server in the farm if the server previously dedicated for UPS
should fail; on
ce the service is re
provisioned and the sync has been re
run, profile data would be back
in the same state as it was pre

HA for Database Servers

To achieve high
availability of the database tier, there are two possible technologies that will work

SharePoint 2010:

Database Mirroring

Failover Clustering

Database Mirroring

Database mirroring provides high availability by replicating the contents of a database server to a
second database server as transactions are committed. The following diagram

SharePoint 2010 natively supports and can be made fully aware of a second (failover) database instance
on a per
content database basis for use with database mirroring.

Failover cluster

Failover clustering is a tech
nology built into Windows Server operating systems.

Failover clustering can provide availability support for an instance of SQL Server. A failover cluster is a
combination of one or more nodes or servers, and two or more shared disks. A failover cluster in
appears as a single computer, but has functionality that provides failover from one node to another if
the current node becomes unavailable. SharePoint Server can run on any combination of active and
passive nodes in a cluster that is supported by S
QL Server.

SharePoint Server references the cluster as a single entity; therefore, failover is automatic and seamless
from the perspective of SharePoint Server.

Failover clustering requires shared storage; each node in the cluster needs to have access to t
he same
storage. The node that is active takes control over the storage resources.

Failover clustering is illustrated in the following diagram:


While SharePoint 2010 supports both mirroring and failover clustering to achieve high
availability for
database services, Navantis recommends use of Failover Clustering.

Mirroring is more complex to set up, demands additional licensed hardware (for the recommended
witness server), and requires a high
bandwidth, low latency connection betwee
n the SQL servers.

Failover clustering requires less effort to set up and manage, but does demand use of shared storage
technology for data. Failover clustering also requires the Enterprise edition of Windows Server 2008 or
Server 2008 R2 on the servers wh
ere the SQL server instance is installed.

Neither mode requires an additional SQL license for the “passive” SQL instance.

HA through virtualization

Note that if the solution is virtualized, the virtualization technology may support additional means to
eve high availability, particularly with respect to outages due to hardware failure. Some
virtualization technologies (such as Hyper
V) allow for migration of a virtual workload from one host to
another in a rapid and near
seamless fashion. Virtualization
provides other advantages such as the
ability to take a ‘snapshot’, or a copy of an entire VM prior to making changes whose impact has not
been fully determined. Virtualization also provides availability through planned outages (such as the
need to reboot
a server after a update to the OS or application) by moving VMs around between
physical hosts that require maintenance. To the end user, the SharePoint service experiences little or no
interruption. Finally, virtualization typically permits the rapid provi
sioning of additional resources (RAM,
CPU, disk), or entirely new farm servers, the need for which may arise out of increased load or a future
desire to offload certain farm services to dedicated servers. Furthermore, every SharePoint role can be
ed in a farm provided adequate resources are made available to the virtual machines; these
resources can consist of memory and CPU for Web Front
End and Application Servers, up to additional
disk space, physical spindles and IO bandwidth plus operations/se
c for the SQL servers.

Planning for Capacity

A planning capacity model (the HP Sizer for Microsoft SharePoint Server 2010) has been used to
determine the necessary hardware to support the expected load on the system. Separating the
SharePoint tier from the

database tier was configured as a requirement (and really needs to be the case
for HA).

The usage is as itemized in the business requirements.

Initial modeling indicates that a single server can take on both the WFE and “indexing” role under
expected load

(obviously this won’t provide any measure of HA for the Intranet). Similar hardware
configured in a WFE role only, should meet the HA requirements (except indexing and searching).

A scenario described as follows was also run against the model:


of 100% (for all 7,000 users)

Peak requests per user per hour of up to 50 (instead of that 2 hits per user per hour)

Content database of 17GB (instead of the initial 9GB).

The mix of activity was weighted as 95% accessing content, and 5% performing search


The degree of modification to stored content was low (most users won’t be uploading new content

Even in this case, a single server should be able to meet the demand of both the WFE (including query)
and indexing roles.

To achieve g
ood performance, caching will be used in the environment. This is expected to reduce load
on the SQL database tier, as well as limit the network traffic between servers.

The hardware used in the model was based on HP technologies, but similarly specified s
ervers from
other providers should operate at similar levels of performance.

Note that the Sizer identifies that without need for HA, a single server would be capable of handling all
roles (including SQL) at the modeled load levels. Should

ne there is no need for HA for
the Intranet, this would be a potentially valid solution, but not one recommended by Navantis, mainly as
a single server solution would not scale, nor be modified as easily as a two
tier farm.

Recommended Hardware

Production hardware requirements for SharePoint 2010 are based on the Server OS used, requirements
to achieve adequate performance under predicted load, best practices, as well as the recommended
technology to achieve high
availability. Note that SharePoin
t 2010 demands a 64 bit architecture (which
is also preferred for performance reasons) on all farm servers (including SQL).

The recommended hardware for the Production SharePoint 2010 Intranet is as follows:

SharePoint Web Front
End Servers (2 required).




4 processor cores, 2.66

GHz or faster


8 GB


System Drive (RAID1) on 2 x 72GB disks

Index Catalog (RAID10) on 2 x 72GB disks


2 x Gigabit Ethernet (one for NLB network)

SharePoint Application/Search
Index Servers (2 required).




4 processor cores, 2.66

GHz or faster


16 GB


System Drive (RAID1) on 2 x 72GB disks

Index Catalog (RAID10) on 2 x 72GB disks


2 x Gigabit Ethernet (one for NLB network)

Database Servers




quad core processor, 2.66

GHz or faster


16 GB



Drive (RAID1) on 2 x 72GB disks

LUN: Content DB Data + Logs and Temp DB Data + Logs (32GB, RAID10), 2 disks


DB Data + Logs and Search DB Data + Logs (43GB, RAID
), 3 disks

LUN: Quorum disk (500MB)


2 x Gigabit Ethernet (one for cluster network)

If the shared storage allows for easy provisioning of additional LUNS, it is recommended to split the
TempDB onto a separate LUN, and further physically separate database data files from log files.
However it is not necessary to do this to achieve good levels of performance, under the estimated load

Support for virtualization

The servers in the

Intranet can be virtualized, and is a supported scenario (given that the virtualization
technology chosen is supported by Microsoft).

This includes both the SharePoint farm web/app servers, as well as the database server.

If the database server is virtual
ized to support failover clustering (what is referred to as a Guest
Clustering configuration), the shared storage must be presented to the virtual SQL servers as iSCSI. This
is the only shared storage type supported by virtual hosts in a Microsoft failover


Virtualization may itself provide sufficient mechanisms to achieve required high availability.

Recommended Software

Operating Systems

SharePoint 2010 is supported on Windows Server 2008 SP1 and beyond (including Window 2008 R2
RTM and SP1).
Navantis recommends use of the most current Operating Systems for reasons of
performance, manageability, and extended lifetime of support, as well as support for potential future

Navantis recommends:

For WFE servers, 64 bit Windows Server 2008 R2

Standard (NLB is an included feature of Server 2008 R2

Application server (also called Index server): 64 bit Windows Server 2008 R2 Standard.

Database servers: 64 bit Windows Server 2008 R2 Enterprise (to take advantage of Failover clustering)


SharePoint 2010 is supported with SQL x64 versions going back to SQL 2005 SP2. However Navantis
(and Microsoft) recommend using newer versions of SQL server for SharePoint 2010.

Recommended database version is SQL Server 2008 R2 Standard (which
supports 2
node clustering).


Five Microsoft Office SharePoint Server 2010 licenses are required for Production. Given that none of
the features enabled with the Enterprise version (such as InfoPath


and Performance Point) are required, the Standard edition is sufficient.

SharePoint Server should be updated the latest cumulative update available at the time of deployment.
Additionally, the OS for each farm member server should be updated to latest rec
ommended updates at
the time of deployment.

Client Access License requirements are not considered as part of infrastructure.

Network Requirements

Connections between SharePoint server and database server should be at 1Gbps, and low latency.

If Windows Serv
er NLB is used to load balance client request to web front end servers, switches
connected to the interface must support Windows NLB. Most switches should, but some require special
configuration. This article explains how NLB works:

All members of the farm require low latency access to servers providing Active Directory Services (i.e. a
domain controller) to allow for rapid authe
ntication of users.

The two SQL servers should be connected with a separate ‘cluster’ network. This can be via a crossover
cable, or through a separate VLAN on a switch. A crossover cable is suitable as there are only two nodes
in the cluster.

The two Sha
rePoint servers should be connected with a separate ‘cluster’ network. This can be via a
crossover cable, or through a separate VLAN on a switch. A crossover cable is suitable as there are only
two nodes in the cluster. If more WFEs are added to the clust
er, these will need to be connected
through a switch.

Production Topology

The following diagram represents the required Production topology to meet the afore
requirements around capacity and availability. All Servers except database cluster are
to be virtual:

Note that the database tier could be either a Failover Cluster (recommended), or a pair of mirrored SQL
Servers, with a witness server.

Production Environment Topology

The performance and capacity
requirements for Development and QA are expected to be significantly
less than those for Production, therefore we are able to scale back some of the server specs in these
environments. However, it is often desirable to have at least one pre
production mirr
or the Production
environment at least from a logical design standpoint; in other words, if Production web servers are
deployed in a load
balanced, HA configuration then we may want our QA environment to be similarly
deployed. To mitigate the cost of redun
dant hardware in pre
production we may vertically scale down
the hardware though (fewer CPUs, less RAM etc.). Finally, virtualization plays a key role in Pre
Production environments because of the reduced performance requirements and potential hardware
t savings.

The following diagram illustrates the required server topology for a combined Development and QA
environment, with shared SQL server.