Product/ Design Guide
Windows Sharepoint Services 3.0 WSS
Version 1.0
Written by:
Steve Miles
Last Updated:
05/11/08

Index
1 INTRODUCTION..................................................................................................................... 4
1.1 PURPOSE.......................................................................................................................................................4
1.2 SCOPE...........................................................................................................................................................4
1.3 ADDITIONAL DOCUMENTATION..............................................................................................................................4
1.4 GLOSSARY......................................................................................................................................................5
2 OVERVIEW........................................................................................................................... 6
2.1 WHAT IS WINDOWS SHAREPOINT SERVICES
..................................................................................................................................................................6
2.2 WSS HISTORY..................................................................................................................................................6
2.3 WSS VS MOSS.................................................................................................................................................7
2.4 HOW ARE MICROSOFT OFFICE SHAREPOINT SERVER AND MICROSOFT WINDOWS SHAREPOINT SERVICES RELATED?...................8
2.5 THE DIFFERENCES BETWEEN WSS AND MOSS...........................................................................................................9
2.6 SHAREPOINT TECHNOLOGIES ARCHITECTURAL OVERVIEW..........................................................................................14
2.7 LOGICAL ARCHITECTURE COMPONENTS................................................................................................................17
2.8 WEB APPLICATIONS, DATABASES AND SITE COLLECTION RELATIONSHIPS......................................................................21
2.9 MPS PROVISIONING WITH WSS............................................................................................................................22
3 ARCHITECTURE OF EXAMPLE IMPLEMENTATION........................................................................... 23
3.1 OVERVIEW....................................................................................................................................................23
3.2 WHAT VERSION OF WSS IS DEPLOYED..................................................................................................................23
3.3 .................................................................................................................................23
FARM TOPOLOGY DESIGN
3.4 PERFORMANCE AND SIZING ASSSUMPTIONS...........................................................................................................24
3.5 SOLUTION ARCHITECTURE.................................................................................................................................26
3.6 WEB APPLICATION AND SITE COLLECTION HIERARCHIES............................................................................................27
3.7 AUTHENTICATION METHODS...............................................................................................................................28
3.8 ..........................................................................................................................................28
STORAGE DESIGN
3.9 SERVER AND STORAGE SPECIFICATIONS..............................................................................................................29
3.10 CAPACITY OF PROPOSED ARCHITECTURE............................................................................................................30
3.11 ..................................................................................................................31
DATA PROTECTION AND RECOVERY
...................................................................................................................................... 32
DESIGN GUIDELINES.................................................................................................................32
4 FARM TOPOLOGY................................................................................................................ 33
5 PLANNING SIZING............................................................................................................... 35
5.1 ACCEPTABLE PERFORMANCE GUIDELINES.............................................................................................................35
5.2 ABOUT AVAILABILITY.......................................................................................................................................36
5.3 TYPICAL USAGE.............................................................................................................................................37
5.4 SITE HIERARCHY.............................................................................................................................................38
5.5 ESTIMATING THROUGHPUT TARGETS....................................................................................................................39
5.6 ABOUT SALEABILITY........................................................................................................................................40
5.7 USER RESPONSE TIMES AND CONCURRENCY RATES.................................................................................................42
5.8 .....................................................................................................................44
PLANNING SQL SERVER STORAGE
- 2 / 46 -

6 PLAN FOR DATA PROTECTION AND RECOVERY ............................................................................ 45
7 APPENDIX........................................................................................................................ 46
7.1 REFERENCE LINKS.........................................................................................................................................46
Version history
Contributor(s)
Date Changes from Written by Changes
Version #
Validator(s)
Date Version Reference validated by Comments
- 3 / 46 -

1 INTRODUCTION
1.1 PURPOSE
To provide an Architecture and Design Guide for Windows SharePoint Services 3.0 (WSS).
Sizing and Performance planning are also covered.
1.2 SCOPE
For all that have a requirement to understand the Architecture and sizing and performance of WSS.
1.3 ADDITIONAL DOCUMENTATION
• Microsoft SharePoint Products and Technologies Home Page
• Microsoft Site - What is Microsoft Office SharePoint Server?
• SharePoint Products Comparison .xls download
- 4 / 46 -

1.4 GLOSSARY
Several acronyms and abbreviation are frequently used in this document; the following chart gives a short
explanation or definition of these terms:
WS03 Windows Server 2003
MSSQL Microsoft SQL Server
DB Database
MSCS Microsoft Cluster Service
MSDTC Microsoft Distributed Transaction Coordinator
MOSS Microsoft Office SharePoint Server
WSS Windows SharePoint Services
SPS SharePoint Portal Server – Former product to MOSS
STS Sharepoint Team Services – Former product to WSS
RPH Requsest Per Hour
RPS Requests per Second
- 5 / 46 -

2 OVERVIEW
2.1 WHAT IS WINDOWS SHAREPOINT SERVICES
Windows SharePoint Services (WSS) is designed primarily for use by teams for collaboration. It is an
enabling technology that is included in Microsoft Windows Server 2003. It helps teams stay connected and
productive by providing easy access to the people, documents, and information that they need to make
well-informed decisions and get work done.
The term “SharePoint” is freely used to refer to Microsoft SharePoint Products and Technologies, so to
clarify this a bit further. SharePoint Technologies primarily consist of:
 Windows SharePoint Services (formerly SharePoint Team Services)
Delivers web sites for team collaboration and productivity, facilitating large numbers of
smart places. http://office.microsoft.com/en-gb/sharepointtechnology/default.aspx
 Microsoft Office SharePoint Server 2007 (formerly SharePoint Portal Server SPS)
Builds on top of WSS and connects these places, people, knowledge, and business
processes, facilitating smart organisations.
http://office.microsoft.com/en-gb/sharepointserver/FX100492001033.aspx
SharePoint products are based on a technology for provisioning Web Applications and Sites within. It is an
IIS-based Web Site solution, integrating with IIS through ASP.NET and relying on a SQL Server database
back end for storing configuration data and content. In short, SharePoint combines three different
architectures at its core; IIS, .NET, and SQL Server.
The relationship between IIS web sites, web applications, site collections, sites, and content databases
can be confusing. In SharePoint terminology, the term web application refers to a SharePoint-extended
IIS web site. A web application can include multiple site collections, and each site collection again can
include a top-level site and sub-level sites that share the same configuration settings.
2.2 WSS HISTORY
The first version, called SharePoint Team Services (usually abbreviated to STS), was released at the same
time as Office XP and was available as part of Microsoft FrontPage.
Windows SharePoint Services 2.0 was marketed as an upgrade to SharePoint Team Services, but was in
fact a completely redesigned application. SharePoint Team Services stored documents in ordinary file
storage, keeping document metadata in a database. Windows SharePoint Services 2.0 on the other hand,
stores both the document and the metadata in a database, and supports basic document versioning for
items in Document Libraries. Service Pack 2 for WSS added support for SQL Server 2005 and the use of
the .NET Framework 2.0.
Windows SharePoint Services 3.0 was released in November 2006 as part of the Microsoft Office 2007
suite. WSS 3.0 is built using .NET Framework 2.0 and .NET Framework 3.0 Windows Workflow Foundation
to add workflow capabilities to the basic suite. By the beginning of 2007 WSS 3.0 was made available to
the public. Windows 2000 Server MSSQL 2000 are not supported by WSS 3.0,
- 6 / 46 -

2.3 WSS VS MOSS
Understanding the similarities, differences, and intended usage of these two products is crucial to
planning a successful SharePoint based solution.
The SharePoint Technologies architecture is composed of Web Server Front-Ends running the WSS
application with MOSS plugging-in functionality where required.
There is a fundamental difference in the roles played by WSS and MOSS.
 WSS is based on a collaboration theme in the sense that it's designed to store and share list-
based data and documents.
 MOSS, on the other hand, is based on an aggregation theme.
To use other terminology
• MOSS is based on the definition of Synthesis
• WSS is based on the definition of Analysis.
i.e. A MOSS portal site is useful for aggregating information and documents from many different places,
combining two or more pre-existing elements and results in something new. Whereas WSS is the
opposite, it means 'Breaking up' the aggregated information or portal into dispersed/ distributed web
applications that can connect back to a central MOSS portal.
MOSS can be seen as an umbrella and connecting Portal for all these disjointed and distributed web
applications.
These two roles are quite complementary to one another. WSS allows an enterprise-level company to
create and maintain tens of thousands of collaborative Web sites, while one or more MOSS portal sites
allow users to find what they're looking for by searching through all this content.
Please review the following Microsoft SharePoint Products and Technologies sites.
 Microsoft SharePoint Products and Technologies Home Page
 Microsoft Site - What is Microsoft Office SharePoint Server?
- 7 / 46 -

2.4 HOW ARE MICROSOFT OFFICE SHAREPOINT SERVER AND MICROSOFT WINDOWS SHAREPOINT
SERVICES RELATED?
You may wonder how Windows SharePoint Services relates to Office SharePoint Server 2007?
Microsoft Office SharePoint Server (MOSS), is part of SharePoint Technologies, and runs on top of
Windows SharePoint Services (WSS).
Office SharePoint Server 2007 relies on the Windows SharePoint Services 3.0 technology to provide a
consistent, familiar framework for lists and libraries, site administration, and site customization. The
SharePoint Technologies architecture is composed of Web Server front ends running the WSS application
with MOSS plugging-in functionality where required.
As mentioned in the previous section, these two roles are quite complementary to one another. WSS
allows an enterprise-level company to create and maintain tens of thousands of collaborative Web sites,
while one or more MOSS portal sites allow users to find what they're looking for by searching through all
this content.
MOSS complements WSS by adding manageability features that have been designed to assist users in
navigating through vast amounts of information and documents. It is important to note that MOSS is built
on top of WSS.
Any features that are available in Windows SharePoint Services 3.0 are also available in Office SharePoint
Server 2007. However, Office SharePoint Server 2007 offers enhanced and additional features that are
unavailable on a Windows SharePoint Services site.
For a complete breakdown of the features of Office SharePoint Server 2007 and Windows SharePoint
Services 3.0, please download the product comparison chart:
SharePoint Products Comparison .xls download
- 8 / 46 -

2.5 THE DIFFERENCES BETWEEN WSS AND MOSS
Understanding the similarities, differences, and intended usage of these two products is
crucial to planning a successful SharePoint based solution.
SharePoint Products Comparison .xls download:
http://office.microsoft.com/en-us/sharepointserver/HA101978031033.aspx
Capabilities Windows Office SharePoint Office SharePoint Server
SharePoint Services Server 2007 2007 Enterprise Edition
3.0 Standard Edition
Collaboration X X X
Portals X X
Enterprise Search X X
Enterprise Content X X
Management
Business Process and Forms X
Business Intelligence X
- 9 / 46 -

- 10 / 46 -

- 11 / 46 -

Windows SharePoint Services v3 Features:
33 Features in WSS v3
• • •
AdminLinks DocumentLibrary SiteSettings
• • •
AnnouncementsList EventsList SPSearchFeature
• • •
BasicWebParts fields SurveysList
• • •
ContactsList GanttTasksList TasksList
• • •
ContentLightup GridList TeamCollab
• • •
ContentTypeSettings IssuesList UpgradeLinks
• • •
ctypes IssueTrackingWorkflow WebPageLibrary
• • •
CustomList LinksList WikiWelcome
• • •
DataSourceLibrary MobilityRedirect WorkflowHistoryList
• •
NoCodeWorkflowLibrary WorkflowProcessList
• DiscussionsList
• PictureLibrary • XmlFormLibrary
Microsoft Office SharePoint Services 2007 Features:
107 Features Added in MOSS 2007
• • •
AddDashboard ListTargeting PublishingLayouts
• • •
Analytics LocalSiteDirectoryControl PublishingPrerequisites
• • •
AnalyticsLinks LocalSiteDirectoryMetaData PublishingResources
• • •
BaseSite LocalSiteDirectorySettingsLink PublishingSite
• • •
BaseSiteStapling MasterSiteDirectoryControl PublishingStapling
• • •
BaseWeb MigrationLinks PublishingWeb
• • •
BaseWebApplication MySite RecordsManagement
• • •
BDCAdminUILinks MySiteBlog RedirectPageContentTypeBi
• • nding
BDR MySiteCleanup
•
• • RelatedLinksScopeSettingsLi
BizAppsCTypes MySiteHost
nk
• •
BizAppsFields MySiteLayouts
• ReportCenterCreation
• •
BizAppsListTemplates MySiteNavigation
• ReportCenterSampleData
• •
BizAppsSiteTemplates MySiteQuickLaunch
• Reporting
• •
BulkWorkflow Navigation
• ReportListTemplate
• •
BulkWorkflowTimerJob NavigationProperties
• ReviewWorkflows
• •
DataConnectionLibrary OffWFCommon
• SearchAndProcess
• •
DataConnectionLibrarySta OSearchBasicFeature
• SearchWebParts
•
pling OSearchCentralAdminLinks
•
• SharedServices
•
DeploymentLinks OSearchEnhancedFeature
•
• SignaturesWorkflow
•
DMContentTypeSettings OSearchPortalAdminLinks
•
• SitesList
•
EawfSite OSearchSRPAdminLinks
•
• SkuUpgradeLinks
•
EawfWeb OsrvLinks
•
• SlideLibrary
•
EnhancedHtmlEditing OsrvTasks
•
• SlideLibraryActivation
•
ExcelServer OssNavigation
•
• SpellChecking
•
ExcelServerSite OSSSearchSearchCenterUrlFeatu
•
• SPSDisco
ExcelServerWebApplicatio re
•
• SpsSsoLinks
n OSSSearchSearchCenterUrlSiteF
• •
ExpirationWorkflow SRPProfileAdmin
eature
• • •
FeaturePushdown PageConverters StapledWorkflows
• • •
GlobalWebParts PortalLayouts TranslationWorkflow
• • •
GradualUpgrade PremiumRootSite TransMgmtFunc
• • •
Hold PremiumRootSiteStapling TransMgmtLib
• • •
ipfsAdminLinks PremiumSite UpgradeOnlyFile
• • •
IPFSAdminWeb PremiumSiteStapling UserMigrator
• • •
IPFSDocumentConversion PremiumWeb ViewFormPagesLockDown
• •
IPFSSiteFeatures PremiumWebApplication
• • •
IPFSWebFeatures ProfileSynch WebPartAdderGroups
• •
LegacyDocumentLibrary Publishing
- 12 / 46 -

- 13 / 46 -

2.6 SHAREPOINT TECHNOLOGIES ARCHITECTURAL OVERVIEW
This section outlines the basic underlying software architecture principles of both WSS and MOSS.
SharePoint pages are built by combining the web parts into a web page, to be accessed using a
browser. Any web editor supporting ASP.NET can be used for this purpose, even though Microsoft
Office SharePoint Designer is the preferred editor.
WSS pages are ASP.NET applications, as such SharePoint web parts use the ASP.NET web parts
infrastructure, and using the ASP.NET APIs, web parts can be written to extend the functionality of
WSS.
As mentioned in a previous section, SharePoint products are based on a technology for provisioning
Web applications and sites within. It is an IIS-based Web site solution, integrating with IIS through
ASP.NET and relying on a SQL Server database back end for storing configuration data and content.
In short, SharePoint combines three different architectures at its core (IIS, .NET, and SQL Server.
Unlike regular ASP.NET applications, the .aspx which contains the WSS (and MOSS) application
code, resides in SQL Server databases instead of the file system. As such, the regular ASP.NET
runtime cannot process the file. Instead, WSS plugs a custom ''Virtual Path Provider'' component
into the ASP.NET pipeline, which fetches the .aspx files from the database for processing. With this
feature, introduced with WSS 3.0, both the WSS application as well as the data it generates and
manages, could be stored in a database.
At the web server level, standard IIS components, such as the HTTP kernel-mode driver (http.sys)
and the Worker Process (w3wp.exe), perform the initial queuing and routing of requests until they
arrive at the ASP.NET ISAPI filter (aspnet_isapi.dll). Once IIS loads the ASP.NET ISAPI filter, all
incoming requests for a Web site can be passed to ASP.NET, which is important because SharePoint
must eventually receive these requests through ASP.NET. To accomplish this, SharePoint extends
the configuration of the selected Web site by adding a wildcard application map that routes all
incoming requests, regardless of the file name extension, to the ASP.NET ISAPI filter.
You can see this in IIS Manager after you install WSS 3.0 using the Basic installation option. The
WSS setup routine deactivates the existing default IIS Web site on the server and creates a new
default Web site on port 80 that has the ASP.NET wildcard application map defined.
- 14 / 46 -

Note that when you create a Web application using the SharePoint 3.0 Central Administration site,
WSS adds the ASP.NET wildcard application map to the selected IIS Web site and creates the
global.asax and web.config files in the Web site's root folder. Each Web application uses its own set
of top-level global.asax and web.config files.
To process requests and return meaningful information to browsers, WSS 3.0 and MOSS 2007 rely
on the standard ASP.NET page parser, which compiles the requested ASP.NET pages or processes
them in no compilation mode. But the ASP.NET pages that SharePoint passes to the ASP.NET parser
are not necessarily located where they appear to exist. For example, you will not be able to find a
default.aspx file in the root folder of a SharePoint-extended Web site, such as the SharePoint 3.0
Central Administration site, yet you are opening default.aspx when displaying the home page of
that Web site. It is the SPVirtualPathProvider component that virtualizes the environment by
loading the page content from the local file system or a SQL Server content database and passing it
as a virtual file to the ASP.NET page parser.
- 15 / 46 -

- 16 / 46 -

2.7 LOGICAL ARCHITECTURE COMPONENTS
There are a variety of ways you can arrange the components in a logical architecture design. Each
of the components presents different opportunities for sharing and isolation. Before you begin your
logical architecture design:
• Know what your sharing and isolation goals are.
• Evaluate the tradeoffs for each choice.
This section describes each particular logical architecture component:
Server farms
Technically, server farms are not a logical architecture component. However, a server farm
represents the top-level element of a design. Individual server farms provide physical isolation.
You can satisfy many isolation requirements on a single server farm. For example, you can use
different Internet Information Services (IIS) application pools with different process identities to
achieve isolation at the Process Level. You can also use separate Web Applications to achieve
isolation at the Web Application Level. Use separate Site Collections to isolate at the Site Level.
In addition to isolation requirements that might require more than one server farm, an organization
might implement multiple server farms to satisfy performance and scale goals.
Application pools
An application pool is a grouping of one or more URLs (or Web sites as they are represented in IIS)
served by a worker process. Each application pool has its own worker process and identity (security
account) which prevents two processes from interacting.
The memory overhead of an application pool is 30-50 megabytes (MB) plus any memory for the
applications running in the application pool process space. The limit for the number of application
pools is influenced by the available memory on the system. That is, the number of application pools
is dictated by the following two factors:
• Available addressable memory.
• The size of the application running in the application pool.
The general guideline for acceptable performance is to use eight or fewer application pools.
Application Pools sharing and isolation
IIS application pools provide a way for multiple sites to run on the same server computer but still
have their own worker processes and identity. This can help to prevent an exploit on one site which
enables the attacker to inject malicious code that can attack sites in different application pools.
- 17 / 46 -

Web Applications
A Web application is an IIS Web site that is created and used by SharePoint Products and
Technologies. Each Web application is represented by a different Web site in IIS. You assign each
Web application a unique domain name, which helps to prevent cross-site scripting attacks.
Each ASP.NET page generates a separate dynamic-link library (DLL) for each Web application. The
separate DLLs consume memory, limiting the number of Web applications that can run on a server.
The guideline for acceptable performance is to implement 99 or fewer Web applications.
Web Applications sharing and isolation
Each Web application has a unique domain name, which helps to prevent cross-site scripting
attacks.
Generally speaking, use dedicated Web applications to:
Separate content available to anonymous users from content available to authenticated users.
Content Databases
By default, all content for a Web application is stored in one content database. You can separate
content into multiple content databases at the site collection level. A content database can include
one or more site collections. A single site collection cannot span multiple databases. Backing up and
restoring sites takes place at the content database level.
The guideline for acceptable performance is to implement 99 or fewer content databases per Web
application.
Content Databases sharing and isolation
Planning for databases enables you to either optimize for efficiency (multiple site collections sharing
a database) or isolation (one database per site collection).
Achieve scale efficiency by managing databases to the maximum target size. In this case, you
configure database settings to add new site collections to existing databases until the maximum
number of site collections has been reached. You calculate the maximum number of site collections
by estimating the average or maximum size of site collections divided into the maximum size target
for the database. This approach works well when you expect a large number of small site
collections, such as My Sites.
Content Databases planning recommendations
Choose one of the following two approaches:
• Establish target sizes for content databases with appropriate size-warning thresholds.
Create new databases when size-warning thresholds are reached. With this approach, site
collections are automatically added to the available database or databases, based on size
targets alone.
• Associate site collections with specific content databases. This approach enables you to
place one or more site collections in a dedicated database that can be managed
independently from other databases.
- 18 / 46 -

Site Collections
A site collection is a set of Web sites that have the same owner (e.g. a resellers customer) and
share administration settings. Each site collection contains a top-level Web site and can contain one
or more subsites.
The recommended guideline for acceptable performance is to implement fewer than 50,000 site
collections per Web application. Scaling out by distributing site collections across multiple database
servers provides additional storage capacity and throughput.
Site Collections sharing and isolation
Site collections introduce several sharing and isolation opportunities that affect permissions,
navigation, and feature deployment.
The following items can be shared within a site collection and cannot be shared across site
collections:
• Master pages
• Page layouts
• Images
• Site templates
Additionally, permissions and navigation are isolated at the site collection level in the following
ways:
• Subsites within a site collection can inherit permissions from the top-level site.
• Site collections cannot inherit permissions from other site collections.
• There is no built-in navigation from one site collection to another.
Finally, Windows SharePoint Services 3.0 search provides search results only within a single site
collection. Windows SharePoint Services 3.0 search does not include results across multiple site
collections.
It is important to note that although permissions are enforced on individual sites, the sites are still
vulnerable to cross-site scripting attacks from other sites within the domain (Web Application).
Sites
A site is one or more related Web pages that are hosted inside a site collection.
The guideline for acceptable performance is to implement fewer than 250,000 sites per site
collection. You can create a very large total number of Web sites by nesting the subsites. For
example, 100 sites, each with 1000 subsites, is 100,000 Web sites. The maximum recommended
number of sites and subsites is 125 sites with 2,000 subsites each, for a total of 250,000 sites.
Sites sharing and isolation
Sites include built-in navigation from one subsite to another within a site collection. There is no
built-in navigation from one site collection to another.
As with site collections, separate sites are vulnerable to cross-site scripting attacks from other sites
within the domain.
- 19 / 46 -

HTTPS
To configure HTTPS, a certificate needs to be applied to the Web site at an IIS Web site. Therefore,
HTTPS can only be configured at the Web application level in Windows SharePoint Services 3.0.
In hosting scenarios, the hosters can configure a single Web application with HTTPS and then create
multiple host-named site collections within that Web application. Each Web site is technically
sharing a single certificate.
However, if the requirement is to apply a unique certificate per site, the hoster will need to create
Web applications (which by definition do not scale as high as site collections in Windows SharePoint
Services 3.0).
The only way to share a certificate is to have:
• Wildcard certificates for domains declared for WSS installed on WSS servers, for example:
*.companyx.com
• Every WSS domains formatted like, for example:
Sub-site1.companyx.com
Sub-site2.companyx.com
Configure authentication for SharePoint Web applications
Authentication in Windows SharePoint Services 3.0 is configured at the SharePoint Web application
level. This means that all customer sharing the same Web Application will share the same
authentication method(s).
In the proposed design all customers will share the same web application, so will share the same
authentication method(s).
- 20 / 46 -

2.8 WEB APPLICATIONS, DATABASES AND SITE COLLECTION RELATIONSHIPS
In addition to Web site content, SharePoint also stores configuration data in a SQL Server database.
SharePoint keeps the configuration data separate from the content because the configuration data
is global in nature while the content is specific to each individual Web application and site collection.
Accordingly, a Web farm can only have a single configuration database but it can have multiple
content databases.
All WSS servers in the Web farm use the same configuration database to share metadata,
configuration settings, and information about every single IIS Web site that has been SharePoint-
extended in the Web farm. Individual Web applications, on the other hand, can be associated with
one or more content databases (though each content database can only be associated with one
Web application).
The relationship between IIS Web sites, Web applications, site collections, sites, and content
databases can be confusing. In SharePoint terminology, the term Web application refers to a
SharePoint-extended IIS Web site. A Web application can include multiple site collections, and each
site collection again can include a top-level site and sub-level sites that share the same
configuration settings.
Among other things, creating multiple site collections enables you to delegate site collection
administration to different users and groups i.e. a reseller would delegate admin to its customer for
their site collection.
A single site collection cannot span multiple content databases, but a Web application can use
multiple content databases for multiple site collections to increase scalability and mitigate the
performance impact of a large site that generates a significant amount of database activity on other
SharePoint sites.
The below diagram illustrates the relationships between the Web Application, Content Databases
and Site Collections. A site collection may have a dedicated content database or multiple site
collections can share the same content database.
- 21 / 46 -

2.9 MPS PROVISIONING WITH WSS
One WebApp/ One single content DB
The way MPS provision WSS limits its implementation to One single Webapp with One single
content database.
When you create a WSS parent site associate to a company, you define a site collection in the
content database.
The HMC administrator will have to monitor the size of the content database and will be able to
move the data of site collections in other database with the Sharepoint administrator toolkit:
http://blogs.msdn.com/sharepoint/archive/2008/04/30/announcing-the-first-release-of-the-
microsoft-sharepoint-administration-toolkit.aspx
WSS size of the content database
Concerning MS best practices regarding the WSS database size: it is directly associated to the
backup/restore time required following the backup/restore solution deployed.
With a dedicated Backup/restore solution like DPM it is acceptable to have a 300 GB WSS content
database. Following the capacity planning to be defined; it will be possible to distribute site
collections to other database via the administrator toolkit.
As already confirmed, MPS doesn’t have a WSS resource manager. This could be the object of a
future requirement to define for a next version.
- 22 / 46 -

.
3 ARCHITECTURE OF EXAMPLE IMPLEMENTATION
3.1 OVERVIEW
This section contains a high-level overview of an example proposed WSS Architecture, this is based
on the implementation of WSS for HMC.
3.2 WHAT VERSION OF WSS IS DEPLOYED
Windows SharePoint Services v3.0 is deployed on an x64 platform with supporting SQL Server x64.
3.3 FARM TOPOLOGY DESIGN
Components are scaled to two tiers.
• Web (Including logical App Tier) - Front-End Web/App Servers
• Database Tier - Database Servers
Availability and Redundancy is at both the Web Tier and the Database Tier.
• Add additional Front-End Web Servers – Load Balance user requests/queries across multiple
front-end web servers. Supports increased user numbers and increases page rendering.
• Hardware Load Balancing will be provisioned, as opposed to software Load Balancing (NLB).
• SQL Server Failover Clustering (MSCS) – For failover protection and increased availability and
redundancy of database servers.
- 23 / 46 -

3.4 PERFORMANCE AND SIZING ASSSUMPTIONS
This section aims to define a Pro (Light) User profile and an Enterprise (Heavy) User profile. This
will be based on User Requests Rate and User Concurrency. Once we have defined these profiles we
can then use these performance assumptions to calculate the resources required and implement a
suitable deign and architecture to sustain load within SLA performance.
The Solution Architecture Section is that design based on the performance assumptions identified
here.
This section can be used to change the value of these assumptions to accommodate an
organisation’s characteristics. The result might be a different throughput target for the
organisation.
Useage Profile Definitions
The following profiles are based on a total user base of 21,000 users. With 1/3 being Pro customers
and 2/3 being Enterprise customers at 10% concurrency.
• Typical Professional Useage Profile defined as 7,000 users (1/3) at 10% concurrency
making 36 Requests Per Hour (RPH)
• Typical Enterprise Useage Profile defined as 14,000 users (2/3) at 10% concurrency
making 60 Requests Per Hour (RPH)
- 24 / 46 -

Typical Professional Usage Profile
Typical Professional Useage Numbers Comments
Profile
7000
Total Users
700
Concurrency at 10%
10 GB
DB size max per customer
DB size avg. per org. %
10 %
max.
1GB
DB size avg. per org
Avg. # of users per
8
company.
Generated Page Requests 36 RPH An active user will
per user generate a request every
100 seconds.
RPH/ RPS at 10% 25200 RPH / 7 Each response per second
concurrency RPS of throughput supports
100 simultaneous users
and 1,000 total users.
Typical Enterprise Usage Profile
Typical Enterprise User Profile Numbers Comments
14000
Total Users
1400
Concurrency at 10%
1 GB
DB size max per customer
DB size avg. per org. %
100 %
max.
1 GB
DB size avg. per org
30
Avg. # of users per org.
Generated Page Requests 60 RPH An active user will
per user generate a request every
60 seconds.
RPH /RPS at 10% 84000 RPH / 23 Each response per second
concurrency RPS of throughput supports 60
simultaneous users and
600 total users.
A GREATER NUMBER OF USERS OR GREATER GENERATED PAGE REQUESTS, REQUIRES A
HIGHER RPS TARGET FIGURE TO ACHIEVE THE SAME USER RESPONSE TIME.
- 25 / 46 -

3.5 SOLUTION ARCHITECTURE
WSS 3.0 on HMC
Reference Architecture
Load
Balancer
FrontNet
Front-End
Web Servers
BackNet
SQL Server
Failover Cluster
User Requests
Load Balanced Front-End Web
Servers
Clustered computers
running SQL Server
- 26 / 46 -

3.6 WEB APPLICATION AND SITE COLLECTION HIERARCHIES
In the chosen Hierarchy the Web Application (SharePoint Custom Default Website listening
on Port 80 Web) is dedicated to the reseller i.e. two resellers cannot share the Web App
listening on Port 80. This is a limitation of this Hierarchy proposed by Microsoft and inherent
to IIS. However, each resellers individual customer has a dedicated site collection.
Please refer to the following Site Hierarchy diagram
Site Hierarchy for Reseller and its
customers
Each individual customer or organization has a dedicated site
collection.
This hierarchy:
• Maps to the shared hardware with SAN server farm layout
.
• Features SharePoint site isolation: Separate site collections are used to allow
for scale while still protecting from most data and security attacks However ,
.
this architecture is still vulnerable to cross site scripting attacks from other
-
sites within the domain.
• Each Resellers customer is provisioned with their own Site Collection it is
.
critical that each hosted customers site collection is separate and isolated
from every other customers site collection.
• All Resellers Customers share the same Web Application i.e. the same
Sharepoint Default website and the same App Pool. There is no isolation at
the web app level between customers.
Shared front-end Web servers and
content databases
Reseller Web application hosting
multiple site collections
Root Sharepoint Custom Default WebSite
(Port80)
Customer A (site collection)
Customer A Home
(top -level Web site)
My Site (subsite)*
Team B (subsite)*
Customer B (site collection)**
* Customers of Reseller can add subsites as required. Subsites within a collection share
navigation, permissions, lists and design elements. This is a limitation of this site site hierarchy .
** Add Site Collection as required for each customer of reseller.
- 27 / 46 -

3.7 AUTHENTICATION METHODS
<ADD CONTENT>
3.8 STORAGE DESIGN
As already confirmed, the way MPS provision WSS limits its implementation to One single Webapp
with One single content database. When you create a WSS parent site associate to a company, you
define a site collection in the content database.
The proposed design has the defining factor of a Single Content DB no larger than 300GB for best
practices. This design is not intended to scale past the single Content DB limitation of 300GB.
Concerning MS best practices regarding the WSS database size: it is directly associated to the
backup/restore time required following the backup/restore solution deployed.
With a dedicated Backup/restore solution like DPM it is acceptable to have a 300 GB WSS content
database.
The solution to this will be to distribute site collections to other database via the Sharepoint
administrator toolkit.
At this time, MPS doesn’t have a WSS resource manager. The HMC administrator will have to
monitor the size of the content database and will be able to move the data of site collections in
other database with the Sharepoint administrator toolkit:
http://blogs.msdn.com/sharepoint/archive/2008/04/30/announcing-the-first-release-of-the-
microsoft-sharepoint-administration-toolkit.aspx
Below are outlined the key storage design concepts.
• One fail-over clustered instance of SQL will be used. The configuration and content
database will reside on the same SQL Server.
• All Resellers customers will share a single content database, whether they are Professional
or Enterprise customers. Again this is a limitation of this WSS Topology.
The following table outlines the SAN storage required for SQL.
*Actual hard disk space requirements depend on the system configuration and the applications and
features that are chosen to be installed.
Database storage disk space should be based on a 1:12 ratio of content to database capacity. That
is, if you plan for 100 GB of content, you need at least 120 GB of available disk space, plus
additional space for transaction logs.
The following table outlines the number of LUNs required on the SAN.
LUNs Comments Size
Quorum Q:\\ 2 GB
MSDTC R:\\ 2 GB
SQL Data S:\\ 400 GB
SQL Logs L:\\ 100 GB
Total LUNs Size 504 GB
- 28 / 46 -

3.9 SERVER AND STORAGE SPECIFICATIONS
SharePoint Web Servers:
• 3 x Servers x64 – Two Dual-Core Processors (3.0 GHz Min)
• 16GB Ram
• Disks Local – 2 x Drives RAID1
• OS: Windows 2003 R2 SP2 x64.
• SharePoint WSS 3.0 – latest stable SP
• Microsoft .NET Framework 3.0
SharePoint SQL – Failover Cluster (MSCS)
• 2 x Servers x64 – Four Dual-Core processors (3.0 GHz Min)
• 32GB Ram.
• OS: Windows 2003 R2 SP2 x64.
• SQL Server2005 Enterprise x64 SP2
SharePoint SQL SAN Storage
 Raid VRAID1 (RAID Levels 10 & 5 not applicable to EVA SAN)
MSCS QUORUM LUN
o
MSDTC LUN
o
SQ L DATA LUN
o
SQL LOGS LUN
o
- 29 / 46 -

3.10CAPACITY OF PROPOSED ARCHITECTURE
This section aims to outine the scale supported for the Pro User profile and an Enterprise User
profile on the current proposed Architecture of 3 Front-End Web Servers and a MSSQL Single
Instance Failover Cluster (or to use older MS terminology, two nodes in a an active/passive cluster
configuration).
The performance and sizing metrics will be based on variables of User Requests Rate and User
Concurrency.
Profile Definitions
Load Request rate Supported users
Each response per second of throughput
20 requests per hour. An active user will
Light supports 180 simultaneous users and
generate a request every 180 seconds.
1,800 total users.
Each response per second of throughput
36 requests per hour. An active user will
Typical supports 100 simultaneous users and
generate a request every 100 seconds.
1,000 total users.
Each response per second of throughput
60 requests per hour. An active user will
Heavy supports 60 simultaneous users and 600
generate a request every 60 seconds.
total users.
The following profiles are based on of total users 1/3 being Pro customers and 2/3
being Enterprise customers.
Scenario 1
Light profile for Pro ; Typical profile for Enterprise
Numbers
330,000
Total supported Users
33,000
Concurrency at 10%
15,000
Pro Supported concurrent users
18,000
Ent Supported concurrent users
Scenario 2
Typical profile for Pro; Heavy profile for Enterprise
Numbers
190,000
Total supported Users
19,000
Concurrency at 10%
9,000
Pro Supported concurrent users
10,000
Ent Supported concurrent users
- 30 / 46 -

3.11DATA PROTECTION AND RECOVERY
- 31 / 46 -

DESIGN GUIDELINES
- 32 / 46 -

4 FARM TOPOLOGY
Many questions arise in the design phase that relate to the decision criteria for the selection of number
and organization of servers in a server farm design for WSS. Looking at the factors that rule the decision
making in this context; the answers are no different to many other solutions i.e.
· Availability
· Performance
· Capacity
Each of the above factors, is important to consider while trying to achieve a workable design for WSS (or
MOSS) based solutions.
This section will focus on the baseline server farm configuration for a typical WSS installation.
A recommended WSS deployment topology is composed of three Virtual (Logical)l layers:
· Web Front End Layer
· Application Layer
· Database Layer.
Virtual (Logical) because nobody enforces that there need to be all these layers isolated and separate
server(s) attached to each layer.
Based on the above mentioned factors, let’s say we conclude that the layers (roles), all of them aggregate
in a single physical server which of course is not recommended for production scenarios. This results in a
single server farm.
Single Server Farm
Single Server Farm, as the name suggests is deprived of the luxury of a lot of hardware and everything
resides in a single box. This can be used for demonstration, proof of concept or evaluation purposes.
Although this topology is not recommended for production environment, but still in cases where there are
low number of users and performance bottlenecks are tolerable to a large extent, this configuration can
be useful.
- 33 / 46 -

Two Server FarmThere might be cases where due to some of the factors (mentioned above), one or
more of the layers be represented by separate servers (one or more for each role based on the
redundancy requirements). This is the starting topology for most of the scenarios is a two server farm
where one server acts as a database server and the other serves WFE and Application Server Roles.
This topology is typically useful when the data needs to be isolated and flexible enough to be scaled to
multiple servers in future.
Three Server Farm (Adding the Application Layer)
This topology typically introduces another layer and hence the three layers now are isolated and each
represented by one or more servers. Each of these roles may also introduce redundancy by adding
redundant hardware and using the load balancing techniques.
What is important to note is that the server farms depicted above are differentatied by the number of
layers and not the number of servers to use in a particular farm topology.
Each of the above farm configuration is different from the other due to the introduction of roles and
representation of roles at different tier levels. A three-server farm, for instance, may also be achieved by
adding a redundant database server to the above-discussed two-server farm or by adding a redundant
WFE server.
[Add content that examines the factors that affect the number of servers in each of the server farms
discussed above]
- 34 / 46 -

5 PLANNING SIZING
This section covers an overview of the key concepts of platform sizing for availability and saleability.
5.1 ACCEPTABLE PERFORMANCE GUIDELINES
Capacity is directly affected by scalability. The following table lists the recommended guidelines
Guidelines for acceptable
Site object Notes
performance
Total farm throughput
Site Collection 50,000 per web application degrades as the number of
site collections increases.
The maximum recommended
number of sites and subsites
Web site 250,000 per site collection is 125 sites with 2,000
subsites each, for a total of
250,000 sites.
Subsite 2,000 per web site
Site collection 50,000 per Web application
Content database 100 per Web application
Site collection 50,000 per database
Logical architecture Guidelines for acceptable
Notes
object performance
IIS application pool 8 per Web server
Site collection 50,000 per Web application
Content database 100 per Web application
Site collection 50,000 per database
- 35 / 46 -

5.2 ABOUT AVAILABILITY
Availability management is concerned with the ability of a system to respond predictably to
requests.
One of the most common measures of availability is number of nines. This translates into the
percentage of time that a given system is active and working. For example, a system with a 99.999
uptime percentage is said to have five nines of availability. The following table correlates the
number of nines to calendar time equivalents.
Acceptable uptime Downtime per Downtime per Downtime per
percentage day month year
95 72.00 minutes 36 hours 18.26 days
99 14.40 minutes 7 hours 3.65 days
99.9 86.40 seconds 43 minutes 8.77 hours
52.60
99.99 8.64 seconds 4 minutes
minutes
5.26
99.999 0.86 seconds 26 seconds
minutes
Windows SharePoint Services 3.0 supports scalable server farms for high availability and
performance. Typically, availability is the first consideration in determining the number of servers to
start with. After factoring in availability requirements, performance and capacity planning also play
a role in determining both the number of servers and the size or capacity of the servers in a server
farm. Adding additional servers to meet these goals also increases the overall availability of your
service* (*see notes on scaling web server front ends later)
- 36 / 46 -

.
5.3 TYPICAL USAGE
Determining number of users and user types
A key feature in understanding server capacity is to understand the users. How many users are
their in the organisation. Will they all be using the sites based on Windows SharePoint Services 3.0
at the same time, and for the same reasons?
Determine number of users
Step one in understanding the users is to estimate how many users will use the SharePoint sites.
Considerations include:
 How many users in total do you expect to use the sites?
 How many users do you expect to use the sites concurrently?
Identify how users will interact with sites
Step two is to identify how users will interact with the SharePoint sites. Identify what percentage of
users are expected to use specific feature sets in the sites. Considerations include:
• Communication Will users view announcements, calendars, and so on, or contribute
items to those lists?
• Collaboration Will users add or change items in task lists or discussion boards?
• Document storage Will users save to document libraries, or check documents in and
out?
• Search Will users search for people, content, or information in the sites?
The below table shows the typical breakdown of usage of a WSS Farm.
Type of subsite Percent of total
Team sites 55%
Document workspace 20%
Meeting workspace 10%
Blog 10%
Wiki 5%
- 37 / 46 -

5.4 SITE HIERARCHY
Decide whether to use individual site collections or subsites within one site collection
You must decide whether to create your sites as top-level Web sites in separate site collections, or
as subsites within the same site collection. This decision is based on how much the sites have in
common with each other, whether you want to be able to manage them individually, and whether
you want them to share elements, such as navigation or search.
Within a site collection, all sites can use the same:
 Navigation bars (top link bar and breadcrumb navigation)
 Content types
 Workflows
 Security groups
 Lookup fields across lists
 Search scope
 Feature set
Choose top-level Web sites in separate site collections when you:
 Need separate security for different sites.
 Want to have a separate search scope for that site only.
 Want to use quotas to separately manage the amount of space that each site takes up.
 Want to decentralize your administration
Choose subsites within the same site collection when you:
 Want to share navigation between sites.
 Want to have subsites inherit permissions from parent sites.
 Want to share lists between sites.
 Want to share design elements (such as themes or styles) between sites.
- 38 / 46 -

5.5 ESTIMATING THROUGHPUT TARGETS
Throughput is the number of operations that a server farm can perform per second. Ideally the
number of operations that are requested per second is lower than the number that can be
performed. If the number of operations that is requested exceeds the number that can be
performed, user actions and other operations take longer to complete.
Throughput is measured in requests per second (RPS). RPS measurements can be converted to the
total number of users by using a model of typical end-user behaviour. Like many human
behaviours, there is a broad range of \"typical\" behaviour.
The user model for Windows SharePoint Services 3.0 has the following two variables:
Concurrency - The percentage of users that are using the system simultaneously.

Request rate — The average number of requests per hour that an active user generates.

Concurrency is discussed more in the next section.
- 39 / 46 -

5.6 ABOUT SALEABILITY
Saleability is the ability of a system to continue to function well when it is changed in size or
volume in order to continue to meet a user need.
There are two common methods of meeting saleability demands.
 Scale Vertically – To Scale Up means to add resources to a single node in a system. I..e.
adding more or faster CPU’s, Memory, Disks.
 Scale Horizontally – To Scale Out means to add more nodes to a system i.e. to add
additional front-end web servers or to add more nodes to a failover cluster as some
examples.
Throughput vs. number of web servers
Through general experience, farm throughput reaches a plateau at 5 Web servers per database
server, and does substantially change when additional Web servers are added.
Although you can deploy up to 8 Web servers per database server, substantial throughput gains
may not be seen after 5 Web servers. This is because as the number of Web servers making calls
against a single database server increases, the database server eventually reaches 100% capacity.
 To increase number of users, add Web servers* (diminishing returns, impact on
throughput)
 To increase page rendering performance, add Web servers* (diminishing returns)
 To increase users throughput add Web servers* (diminishing returns)
*While you can add a nearly unlimited number of front-end Web servers to a single farm,
performance gains start to taper off at the following ratios:
3-4 front-end Web servers per database for sites requiring both read and write
o
transactions.
4-5 front-end Web servers per database for sites requiring primarily read
o
transactions.
 Maintain a ratio of no greater than eight Web server computers to 1 Database Failover
Cluster.
 To scale beyond 4-6 front-end Web servers is not initially recommended
Note that systems that only support read operations, such as a static portal site, can
maintain a higher level of throughput than a system that supports both read and write
operations.
- 40 / 46 -

As highlighted in the previous section, you will see from the table that good throughput returns
can be achieved by adding web servers up to approx 5 web servers.
However, as also noted, as web servers are added there will be diminishing returns, that will
impact throughput.
You will notice that scaling past 5 web servers will not increase throughput (the opposite), but
will allow for greater numbers of users.
There is a sliding scale here :
>Web Server beyond 5 = >Users = <Throughput
(where > = Increase and < = Decrease)
Or put into words, where the number of Web Servers increase beyond 5 then there is an increase
in the number of supported users. However, this increase in users means a decrease in
throughput.
Throughput vs. number of site collections
Throughput, measured in RPS, decreases as the number of site collections in a farm increases.
The following figure shows the decrease in throughput when browsing to the home page of
different site collections as the number of site collections in a single content database increases.
Throughput decreases quickly as the total number of site collections increases from 2000
(RPS=265) to 16,000 (RPS=66), then RPS remains approximately 50 as the total number of site
collections increases to 50,000.
- 41 / 46 -

5.7 USER RESPONSE TIMES AND CONCURRENCY RATES
User Response Times - Some organisations might tolerate slower user response times or might
require faster user response times. The expected user response time is a key factor that determines
overall throughput targets.
Throughput is defined as how many requests the server farm can process per second.
A GREATER NUMBER OF USERS REQUIRES A HIGHER THROUGHPUT TARGET TO ACHIEVE THE SAME USER RESPONSE
TIME.
The following table lists throughput targets based on user response times.
Total users Recommended (RPS)
500 .5
1,000 1.0
5,000 5.0
10,000 10.0
20,000 20.0
50,000 50.0
100,000 100.0
The following table describes the response to levels of load.
Load Request rate Supported users
Each response per second of
20 requests per hour. An active
throughput supports 180
Light user will generate a request every
simultaneous users and 1,800 total
180 seconds.
users.
Each response per second of
36 requests per hour. An active
throughput supports 100
Typical user will generate a request every
simultaneous users and 1,000 total
100 seconds.
users.
Each response per second of
60 requests per hour. An active
throughput supports 60
Heavy user will generate a request every
simultaneous users and 600 total
60 seconds.
users.
- 42 / 46 -

Concurrency Rate – This is the percentage of users that are using the solution at the same time.
We have defined the typical profile user concurrency rate below. The following table recommends
throughput targets (RPS figures) based on the total number of users and the concurrency rate.
A concurrency rate of 10% is assumed for Professional customers and 80% for Enterprise
Customers.
From the table below you can determine that If 1 transaction per second supports 1000 user then
• Per second of throughput (1RPS) can support 100 simultaneous users, at the 10%
concurrency rate.
• Per second of throughput (1RPS) can support 80 simultaneous users, at the 80%
concurrency rate.
The following table lists throughput targets in RPS at various concurrency rates.
Total users 10% 80%
500 0.5 2.5
1000 1 8
5000 5 45
10000 10 80
20000 20 160
50000 50 450
100000 100 800
- 43 / 46 -

5.8 PLANNING SQL SERVER STORAGE
Disk Sizing
Please refer to the previous table in previous section on the space required for SQL Server.
In respect to growth potential and peak usage patterns, Maintain a level of at least 25% free space
across disks to allow for growth.
Disk IO
When using RAID configurations use the following formulas to determine the rate of I/Os on
the disk.
RAID Level Formula
RAID 0 I/Os per disk = (reads + writes) / number of disks
RAID 1 I/Os per disk = [reads + (2 * writes)] / 2
RAID 5 I/Os per disk = [reads + (4 * writes)] / number of
disks
RAID 10 I/Os per disk = [reads + (2 * writes)] / number of
disks
- 44 / 46 -

6 PLAN FOR DATA PROTECTION AND RECOVERY
• http://technet.microsoft.com/en-us/library/cc287757.aspx
• http://technet.microsoft.com/en-us/library/cc287741.aspx
- 45 / 46 -

7 APPENDIX
7.1 REFERENCE LINKS
 http://www.sharepointjoel.com/default.aspx
 Sharepoint - How to Create Intranet Chaos:
http://blogs.msdn.com/joelo/archive/2006/12/30/how-to-create-intranet-chaos.aspx
- 46 / 46 -