Architecture Definition Guidance (Part I) [MOSS 2007]

As SharePoint Architect, often I have to deal with various MOSS 2007 installation and configuration scenarios for each of the clients I have consulted. Eventually I ended up with my quick cheat sheet. I ended up putting together two sets of information, one is more focused on Architecture Definition this post and then another one that is focused on Application Configuration focused (Part II). This is Part I of the series focused on Architecture. Most of the information I have collected and put together are from various Microsoft produced content. It was just easier for me to quickly look it up and have a very high level idea of the focused area.

In this post I have tried defining architecture for MOSS server implementations. This post covers the major technical approach topics and highlights the topics that need to be covered, and what kind of information needs to be collected, and reviews some of the known issues and workarounds.

1. MOSS Implementation Objective

• Identify Objective of MOSS Implementation.
• These objectives can be some or combination of the following:
  • Deployment Mode
    • Intranet
    • Extranet
    • Internet
  • Features
    • Web Content Management
    • Information Worker Collaboration.
    • Records Management.
    • Content Publishing
    • Workflows
  • Identify Content Types
    • Structure
    • Un Structured
  • Identify need for Governance and Manageability.
  • Identify Backup and Restore needs.

2. Environment Technical Requirements

2.1 Performance

• Identify User Response Times requirement by using below table:

Response	Response Time	Response Characteristics
Slow	3-5 seconds	User response times can slow to this rate without issue
Recommended	1-2 seconds	The average user response time target
Fast	<1 second	For organizations whose businesses demand speed

• Identify User Load based on below table:

User load	Request rate	Supported users
Light	20 requests per hour. An active user will generate a request every 180 seconds.	Each response per second of throughput supports 180 simultaneous users and 1,800 total users.
Typical	36 requests per hour. An active user will generate a request every 100 seconds.	Each response per second of throughput supports 100 simultaneous users and 1,000 total users.
Heavy	60 requests per hour. An active user will generate a request every 60 seconds.	Each response per second of throughput supports 60 simultaneous users and 600 total users.
Extreme	120 requests per hour. An active user will generate a request every 30 seconds.	Each response per second of throughput supports 30 simultaneous users and 300 total users.

• Based on the user response time that most closely matches your client’s requirements; determine the throughput target based on the number of users.
• Single-server deployment can capably serve up to 1,000 users, 500 users is the fewest listed.

Total users	Slow (RPS)	Recommended (RPS)	Fast (RPS)
500	.4	.5	.7
1,000	.7	1.0	1.2
5,000	4.0	5.0	6.0
10,000	9.0	10.0	12.0
20,000	18.0	20.0	24.0
50,000	40.0	50.0	60.0
100,000	90.0	100.0	120.0

• You can estimate the performance of your starting-point topology by comparing your topology to the starting-point topologies.
• The recommended starting point for most Windows SharePoint Services 3.0 deployments is at least two server computers:
  • Server 1: Front-end Web server and search server computer
  • Server 2: Dedicated SQL Server computer
• Next determine if you need to scale your starting-point topology to meet your performance and capacity goals.

2.2 Availability

2.2.1 Uptime

• To determine availability first determine the Uptime, and then choose the appropriate Server topology.
• Uptime can be measured based on the following table.

Acceptable uptime percentage	Downtime per day	Downtime per month	Downtime per 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
99.99	8.64 seconds	4 minutes	52.60 minutes
99.999	0.86 seconds	26 seconds	5.26 minutes

2.2.2 Server Farm

• To deploy a high-availability MOSS solution, you must deploy a server farm.
• Comparing minimal Server Farm topologies:

#	Roles	Advantages	Disadvantages	Recommendation
3	Two Web Servers with Search on one server One Dedicated SQL Server	Fewer Servers Increases the overall performance of Web Server	Limited availability with no Database Redundancy	Use this topology when performance is more important than data redundancy.
3	One Web Server with Search server Two SQL Server Clustered or Mirrored	Fewer Servers Ensure availability of critical data	Limited availability with temporary loss of user access	Use this topology when availability of critical data is important than loss of user access.
4	Two Web Servers with Search on one server Two SQL Servers Clustered or Mirrored	Ensures availability of both Web Servers and Data.	Need More servers	Use this topology when both performance and availability of critical data is important
5	Two Web Servers One Search Server Two SQL Servers Clustered or Mirrored	Optimizes the performance of the front-end Web server computers by offloading search to a dedicated server	More servers needed than the above server topologies	Most common highly available server farm topology

• Use above chart to determine the most appropriate Farm Topology for your client.

2.2.3 Load Balancing

• If Web server redundancy is required then plan for web server choosing Load Balancing technology.

Technology	How it works?	Advantages	Disadvantages
MS NLB	Runs on Web Servers by routing TCP/IP requests.	Free with Windows Server. Handles up to 32 Nodes	Consumes fewer resources on Web Servers..
Hardware	Uses network to route traffic across web front-ends	Does not affect Web-Front End resources. Provide more than one port load balancing.	Expensive and can be complex to setup.
DNS Round-robin	DNS server round robins for each request among predefined DNS names by canonical order.	Use existing DNS server.	DNS server does not have any knowledge of Server availability. This method is not recommended for MOSS.

• When using MS-NLB be aware of the following:
  • When network card teaming is implemented, NLB may require special configurations.
  • When Virtual technology is used investigate for NLB compatibility.
• When using Hardware load balancing be aware of the following:
  • SSL port load balancing
  • Load balancing multiple ports for the farm.
  • Note the number of VIPs that load balancer can support and plan accordingly.
• While building your environments for Development, QA, UAT and Production, plan for considering Production equivalent load balancing in other environments to avoid the risk of Production only unique configuration.

2.2.4 Scale Out or Up

• To support increased user load scale out your topology by adding more Front-end Web Servers.
• For better performance maintain 1:8 ratios of DB Server to number of Front-End Web Servers.
• To support increased data load scale up your database server.
• Monitor following Performance counters to determine the need for scale out or up:

Performance Counter	Scope	Web Server	Database Server
% Processor Time	Total
% Memory Utilization	Application Pool	Identify correct application pool to monitor. Identify peak memory usage, assign peak memory plush 10% to the application pool.
	Total

2.2.5 Redundancy

• Following server roles can be configured for redundancy
  • Query
  • Excel Calculation Services
  • Office Project Server 2007
• Following server roles cannot be configured for redundancy
  • Index (Each server crawls different content)
  • WSS 3.0 Search
• Windows SharePoint Services 3.0 search application role includes both the search and indexing components that cannot be divided.
  • Windows SharePoint Services 3.0 search is required to provide full text search of Help.
  • However if you are deploying MOSS-which is the most often case-using MOSS search should overcome this restriction.
• MOSS Index and SSP relation:
  • The index role is associated with a Shared Services Provider (SSP).
  • The index role builds one index per SSP.
  • One index server can be associated with multiple SSPs.
  • However, indexes across SSPs cannot be combined.
  • You can deploy multiple index servers to improve capacity. In this case, each index server is associated with different SSPs.
  • If you are deploying a Office SharePoint Server 2007 farm, we recommend that you use the Office SharePoint Server 2007 query server and index server roles. This allows you to scale the query component out, achieving redundancy of the content indexes.

2.3 Performance Improvement

• Consider implementing various caching mechanism support by MOSS. Refer below to choose appropriate chancing.

Caching Method	Scope	Notes
Output caching and cache profiles	Individual page level	Ideal for heavily accessed Web sites that do not need to present new content frequently.
Object caching	Individual Web Part control, field control, and content level	Includes cross-list query caching and navigation caching
Disk-based caching for Binary Large Objects (BLOBs)	Individual BLOB level and caches images, sound, movies, and code	Supports .gif, .jpg, .js, .css, and other image, sound, and code files that are stored as binary large objects

• Consider using SharePoint test data load tool (WSSDW.exe ). This tool can help you to load test data based on an XML configuration file. The tool also supports to delete the test data from MOSS.

2.4 Capacity Planning

• Consider following for storage requirements :
  • Database Server Disk Space requirements
  • Search Server Disk Space requirements.
  • Web Server Disk Space requirements.
• Refer to below table for estimating disk space across your server Farm

Component	Size Estimate	Notes	Database Server	Web Server	Search Server
OS Files	4GB
Swap file	Same as RAM
SQL Install	425MB
Log Files		Based on # of DBs and settings
Config DB	< 1.5GB
Content DB(s)	All Content DBs size x 1.3	Consider the initial content and x1.3. Consider additional space if version is enabled.
.Net 1.1	100MB	Consider if you have components that are .Net 1.1 frame work based and will not be migrated to .Net 2.0		(Optional)
.Net 2.0	230MB
.Net 3.0	60MB
Temporary ASP.NET Files	100MB
WSS 3.0	700MB
MOSS 2007	400MB
MOSS Logs	~50MB
WSS Logs	~50MB	If Usage Reports is enabled, by default the logs will be stored under this location. Consider more space if you are going to use the default space. You can also specify other drive locations.
Content Index	All Content DBs size / 2
Free Space	25%

• For future growth at least consider twice the size of initial content DBs.
• Consider minimum of 25-30% free space for each disk volume.

2.5 Recommended Guide lines for MOSS objects

Object	Scope	Guideline
Site collections	Database	50,000
Web sites	Site collection	250,000
(sub) Web sites	Web site	2,000
Lists	Web site	2,000
Items	List	10 M
Documents	Doc Library	2 M
Documents	Folder	2,000
Document size	File	2 GB
Indexed Documents (MOSS)	SSP	50 M
Search Scopes (MOSS)	Site Collection	1,000
# Profiles (MOSS)	SSP	5 M

Metric	Preferred	IT Max	Cap Guideline
Site Collections /DB	250	5,000	50,000
Database Size/DB	25-50GB	100 GB
Databases/SQL Instance	100	300
Database Size/SQL Instance	2TB	3TB
Child Portals/Farm (Web Apps)	10	100	100
Full Portals/Farm (SSPs)	1	10
App Pools/Server	2-4	10
Worker Processes/Server	1 per 800MB RAM	1 per 500MB RAM
Site Collection Max Quota	5GB	50GB (DB)
File Upload Size	50MB	100MB	2GB

2.6 Backup/Restore

• Backup Components:
  • SQL Server Databases.
  • Files and state from all the Farm Servers.
  • Files and directories include: IIS Metabase, Web,.config, Custom assemblies, Customizations such as Master pages, Styles sheets, Javascript, Themes, Site and List Definitions. Logs from IIS, Events and SharePoint.
  • Index files.
• Backup tools and methods:
  • SQL Server 2005 native Backup and Restore, Database Mirroring or Log Shipping, VSS Writer.
  • Backup restore from SharePoint Central Administration
  • Site Collection Level backup and Restore using STSADM, SharePoint Designer
  • Migration API
  • Data Protection Manager
• SharePoint Recycle Bin
• Third Party tools
  • EMC Backup Manager for SharePoint
  • AvePoint
  • CommVault
  • NeverFail
  • Quest

3. Hardware Requirements

Component	Stand Alone/Web Server	Application Server
Processor	Dual processors that are each 3 GHz or faster	Dual processors that are each faster than 2.5 GHz
RAM	More than 2 GB	4 GB
Disk	NTFS file system–formatted partition with 3 GB of free space plus adequate free space for your Web sites	NTFS file system–formatted partition with 3 GB of free space plus adequate free space for your data storage requirements
Drive	DVD drive or the source copied to a local or network-accessible drive	DVD drive or the source copied to a local or network-accessible drive
Display	1024 × 768 or higher resolution monitor	1024 × 768 or higher resolution monitor
Network	· 56 Kbps or faster connection between client computers and server · For connections between computers in your server farm, 1 gigabit per second (Gbps) connection	· 56 Kbps or faster connection between client computers and server · For connections between computers in your server farm, 1 gigabit per second (Gbps) connection

4. Software Requirements

• Office SharePoint Server 2007 (any editions)
• Following Windows Server 2003 editions with SP1 or later:
• Windows Server 2003, Standard Edition
• Windows Server 2003, Enterprise Edition
• Windows Server 2003, Datacenter Edition
• Windows Server 2003, Web Edition
• Database
• SQL Server 2000 with SP3a or later or SQL Server 2005 with SP1 or later (any editions)
• Some advanced features may require SQL Server 2005 Analysis Services SP1 or later.
• Note that SQL Server full editions cannot be installed on Windows Server 2003, Web Edition

5. Licensing Requirements

• Apart from Windows Server and SQL Server licenses, you need MOSS licenses as following:
  • For intranet hosting:
    • MOSS Server License per server in the Farm.
    • Client Access License as necessary for your client.
  • For internet hosting:
    • This install requires MOSS Internet licensing (MOSSFIS)
    • No Client Access Licensing is required.
  • Now both Server License and Internet License can be combined and installed under single deployment where client wants to use the same deployment as Intranet and Internet hosting.

6. Service Accounts

• MOSS supports more granular set up of account for various services, application pools, search craw and so on.
• You can also use single universal account to both install and configure every account aspect of MOSS install and configuration.
• Below are the recommended individual accounts recommended.

For Production	For Stage
Example Account	Example Account	Account Permission	Purpose
MOSSAdmin	MOSSAdminStage	Domain User	Installation and configuration of the MOSS 2007 servers
MOSSSearch	MOSSSearchStage	Domain User	Search Service Account and Search Access
MOSSSSP	MOSSSSPStage	Domain User	SSP and App Pool Account
MOSSFarm	MOSSFarmStage	Domain User	Used to install and configure the MOSS 2007 Database
MOSSSQLSvc	MOSSSQLSvcStage	Local SQL Server account	SQL Server Service Account

7. Physical Architecture

• When designing environments for MOSS deployment, along with Production environment consider implementing Development and Staging/QA/UAT Environments.
• For the Development and Staging/QA/UAT environments consider Virtual technology.
• Based on the Production environment, try to simulate as much possible in Staging environment, by matching the servers in the Farm and server topology, Load Balancing configurations, DNS, Security settings etc.
• Consider recoding your hardware details in table format as below.

Server Name	IP	Role	Environment	Physical/Virtual	Proc	RAM	Space	Platform
		Front-End	Dev	Physical	2GHz	4GB	C:20GB D:100GB	x32
		App	Stage	Virtual	2GHz	4GB	C:20GB D:100GB	X64
		SQL	UAT		2GHz	4GB		X64

• For large deployments pre-calculate the storage requirements that may be required to support your Staging/QA environments.
• Identify data file copy across network, SQL backup/restore time estimates.

8. Technical Issues and Constraints

• Max List Items
  • Product team recommends that a single list should not have more than 2,000 items per list container.
  • You may be able to manage larger lists to some extent by using views within Office SharePoint Server 2007 that are filtered such that there are never more than 2,000 items returned.
  • The maximum number of items supported in a list with recursive folders is 5 million items
• Search
  • Search in Windows SharePoint Services 3.0 is designed to work only with NTLM. More specifically, the index component in Search requires NTLM. Therefore, in order for Search to be used with any other authentication mechanism, there are certain workarounds that are needed.
  • Search on https is not support. But by building a custom HttpModule that replaces the https with http in the query string.
  • Also be aware that Search in Windows SharePoint Services does not work with FBA and custom authentication providers.
• Windows NT 4.0 Domain
  • Office SharePoint Server 2007 requires Active Directory directory services for farm deployments. Therefore Office SharePoint Server 2007 cannot be installed in a farm on a Windows NT 4.0 domain
• Not supported Server Topologies
  • If the query role is deployed to the same server that hosts the index role, the query role cannot be deployed to any other server computers. This is because the index role recognizes that the query role is on the same server and, consequently, does not attempt to propagate the index.
• x64 bit Platform Considerations
  • .net 1.1 is not installed by default on x64 bit Windows. If you need to run components based on .net 1.1, then IIS needs to be switch to run in 32-bit mode.
  • So check for applications that may be depended on .net 1.
  • Check for availability of x64 bit iFilters for the customer document types.
  • You can mix and math x32 bit and x64 bit servers in a singe server farm.
• Application Level Issues and Constraints:
  • Identify customer implementation specific Issues and constraints.
  • For a given feature identify current usage model if one exists.
  • Identify integration issues if integration with LOB apps, such as security, speed, impact of accessing.
  • Ask if consistence is important over flexibility for certain features.

(I will keep this updated as I find more relevant information….)