Wednesday, November 30, 2011

Architecture and Capacity Planning

  • Sharepoint Products and licenses
  • Critical non-Sharepoint servers
  • Hardware specifications
  • Tools for controlling your deployment
SP 2010 has greatly expanded its functionality from previous versions. New features include the following:
  • Office web applications, where you can display and edit Office documents in the browser
  • The Fluent UI, aka the Ribbon
  • An enhanced social experience, including tagging and notes
  • More flexibility regarding how web applications consume services through service applications.
  • A full-scale business intelligence offering through tools such as Performance Point Services, Reporting Services, and Excel Services
Administrators can anticipate a strong increase in the number and size of servers in their farms. In short, it is expected that  the same user from SP 2007 will come to a SP 2010 farm with more requests per second.

What's in a name?
Windows Sharepoint Service 3.0 (WSS)
Microsoft Office SP Server 2007 (MOSS)

This time around, the names are Sharepoint Foundation and Sharepoint Server 2010.

Sharepoint Foundation

SP Foundation will continue the legacy that WSS has established over the years and should keep that friendly price point that makes it so attractive.

Windows Server 
  • 64-bit software
  • For production deployments, install on either Windows Server 2008 SP2 and later or Windows Server 2008 R2 and later. The following editions of Windows Server are supported:
    • Standard
    • Enterprise
    • Datacenter
Required Additional Software
After you have Windows installed, the server needs to be included as a member of an Active Directory (AD) domain. SP does not support local machine accounts for any type of farm deployment, and the configuration wizard will error out if you try to use a local account.

If you already installed IIS, PowerShell, or one of the other prerequisites, do not worry; all is not lost. The prerequisite installer tool will check up on you. If you did  successfully install and configure one of the requirements, the tool will skip it and move on to the next one. In the case of IIS, if you enabled the role but did not configure it the way Sharepoint needed, the prerequisite installer will just make the necessary changes. So keep that chin up; all is good.

Another common mistake to avoid is adding the server to a domain, or even promoting it to a domain controller (typically only done on a test virtual machine) after adding programs to the server. Programs such as IIS and SQL Server do not always take too well to these changes. make any computer name changes (which adding to a domain does) as soon after installing Windows as possible. Then you can safely continue with getting it ready for Sharepoint.


Windows Vista and 7

  • Windows Vista x64 and Windows 7 x64.
    • Windows Vista SP1 and later.
      • Business edition
      • Enterprise edition
      • Ultimate edition
  •  Windows 7 RTM and later:
    • Professional edition
    • Enterprise edition
    • Ultimate edition
  •  The N and KN editions of the preceding software will also work
 It is absolutely not supported to use a Windows Vista or 7 installation for a production farm. They should only be used for developers who wish to do Sharepoint development locally on their own machine. If development is done in these environments, then it is highly recommended that developers have a test environment to validate their solution before deploying to production.

SQL Server

With Windows Server requirement, Sharepoint also requires SQL Server to be 64-bit. 32-bit SQL Server is not supported. The 64-bit editions of SQL Server that are supported are SQL Server 2005, SQL Server 2008, and SQL Server 2008 R2. SQL Server 2005 requires Service Pack 3 plus cumulative update package 3 for SQL Server 2005 Service Pack 3 (KB967909). SQL Server 2008 requires Service Pack 1 plus cumulative update package 2 for SQL Server 2008 with Service Pack 1 (KB970315). SQL Server 2008 R2 will be supported at its RTM build or later.

Email Servers

Ask the  email administrator to add the IP addresses of all Sharepoint servers to the list of servers that are allowed to anonymously relay mail. If this is not acceptable, then your second option is to install the SMTP port, is not blocked between your servers. Such a blockage can happen at the firewall level or at the local server level. Some antivirus vendors configure their software to block port 25 outbound on all machines. This will stop Sharepoint from sending email, so be on the lookout.

Incoming Email 
Configuring this functionality requires the help of the email administrator, and it is worth noting that it does not require the use of Exchange. This is a multi-step, complex process that touches several pieces, but the core steps are as follows:
  1. Install and configure one of your Sharepoint servers to run the SMTP service. This server will then need to be set up to accept email for the domain you define for Sharepoint. Typically, it would be something line @sharepoint.company.com.
  2. Configure your corporate email server to route mail for @sharepoint.company.com domain. The idea is that when your corporate email server receives that email, it just passes it over to the Sharepoint server.
  3. Go to Sharepoint Central Administration and enable incoming email. You will need to tell Sharepoint that it is looking for emails in the @sharepoint.company.com domain.
  4. Now someone with the manage list permission level can go into his or her list and associate an email address with the list - for example, kdh@sharepoint.company.com.
  5. This associated email address would now need to be configured as a valid contact on the email server.
With this configured, emails will be sent to kdh@sharepoint.company.com. Your corporate email server will relay that mail to the SMTP service running on the Sharepoint server. The SMTP service will then take that email and put it in a maildrop folder. The Sharepoint timer service checks that folder once a minute by default, looking for email. When it finds an email, it routes it to the appropriate list or library based on the address.

You can find detailed configuration information, with multiple scenarios and troubleshooting steps, on TechNet http://technet.microsoft.com/en-us/library/cc262947(office.14).aspx

Text Message (SMS) Service Settings

Sharepoint has  become so cool that it can even send text messages. And since Sharepoint still is not old enough to drive, you do not even have to worry about it texting and driving.  Once the service is configured, users can choose to have alerts sent to email or text message or to both.

The service is pretty straightforward to set up from within Central Administration and can be scoped at either the farm or the web application level. You will need to provide the URL of an SMS sending service. if you do not have one handy, you can click the link on the Mobile Account Settings page in Central Administration to find one based on your preferred wireless provider. Just watch out for this functionality. It can easily become a runway cost.

Hardware Requirements

  • Moss 2007
    • Processor: 2 core/ 3 GHz
    • Ram: 2GB
  •  Server 2010
    • Processor: 4 core/ 2.5 GHz
    • Ram: 8GB
Sharepoint root refers to a folder structure: C:\program files\common files\Microsoft shared\web server extensions\14. In Sharepoint v3, the \12 folder was called the 12 hive, so you may hear some people refer to the Sharepoint root as the "14 Hive". If you do, try not to make fun of them.

Web Servers

Often referred to as web front-end (WFE) servers, these are the machines ultimately responsible for  the rendering of the Sharepoint pages. They typically do not have a high CPU load because they attempt to cache as much content as  possible to avoid doing the same work over and over. To do caching properly, the server does consume quite a bit of RAM, so be sure to dedicate a substantial portion of your spending on this server to RAM.

A key consideration when determining how much memory you might need is the number of application pools you plan to have. In a nutshell, application pools are the various IIS processes that listen for incoming web traffic and then handle it accordingly. In Task manager, you will see each application pool as w3wp.exe. For example, when you create  a new Sharepoint Web application and choose a new application pool, you get a new instance of this process running. Now when you access Sharepoint, this process is actually receiving your request and coordinating with Sharepoint to render your page. When Sharepoint is caching content in memory, it is being stored in RAM associated with this process.

This role requires very little local storage and does not need to be optimized in any way. The only storage this machine is doing is the Sharepoint root, all of the local ULS and IIS logs, and possibly some disk-based BLOB caching. In other words, do not get carried away here and create a 10GB C: drive. Sharepoint occasionally needs to have extra space for temporary files, maybe to unpack a solution or to deploy a service pack, so an 80GB or 100GB C: drive is reasonable for your WFE.


Application Servers


Application server is the generic name for servers that are responsible for providing resources for the various service application. The tricky part of sizing these boxes is that each service  application has a different usage profile, so the requirements will vary depending on what is running on the box and how heavily that functionality is being used. In addition, when building out an application tier, you should consider scaling out versus scaling up. In other words, is it better to have one large application server with a lot of resources but a single point of failure, or several smaller boxes running the same services that provide fault tolerance but require more administration? The following sections describe some of the key types of application servers and their individual considerations.

Query Server

A query server is the server responsible for responding to user search requests. When a user  opens a Sharepoint page, types into the search box, and presses Search, that request is routed by the WFE to the query server. The query server processes the request and then forwards the information back to the WFE for security trimming and rendering of the results.

This server uses CPU and memory to process the request and will try to cache as much of the index as possible within RAM. This role is also unique in that it requires local storage on the machine. The query file is kept on local disks and processed on the server. In environments with large indexes (one million plus items) and high search demand, it is best to optimized the storage of this file for fast retrieval. Conversely, in smaller environments it is not unsual to see the WFE and query server on the same machine.

The Search architecture for Sharepoint 2010 is completely new compared to 2007 and is covered in full detail in next blog.

SQL Servers

1 comment:

  1. Informative article. In this post all the architectural requirements and necessary detail about SharePoint server is explained which is of great help to all its users. I am grateful to you for sharing this detail.
    electronic signature for sharepoint

    ReplyDelete