This series of articles provide an overview of how to plan, build and configure the common SharePoint farm across your organization.

• Part 1 – Architecture and Logical Planning
• Part 2 – Installation
• Part 3 – Development Environment
• Part 4 – Backup and Recovery Strategy
• Part 5 – Virtualization
• Part 6 – Post Deployment (final)

Post Deployment

Manage all SharePoint ports

There are about 20 different ports SharePoint use and they need to be open across firewalls. Refer to “Planning an Extranet Environment for Office SharePoint Server” document for more details. It can be easier to have firewall disabled when configuring SharePoint, and then close all non-SharePoint ports when configuration is done.

Monitor how SharePoint operates

After finishing deployment the actual work for administrators and infrastructure guys starts. They need to monitor the health of SharePoint servers, status of web application and statistic of web sites usage, the growth of content database.

Microsoft recommends using “System Center Operations Manager 2007″ with SharePoint Monitoring Toolkit http://technet.microsoft.com/en-us/library/bb975149.aspx to monitor SharePoint farms. The only drawback is that it’s enterprise level tool and might not be an ideal solution for small SharePoint farms.

On the other hand “SharePoint Diagnostic Tool” is suitable for small farms that simplify the process of analyzing logs for troubleshooting, and helps significantly reduce the time to diagnose issues.

The commercial sector of 3rd party management tools for SharePoint is represented by Quest Manager, DocAve and others. Quest Manager is one of the best tools that provide detailed information about how SharePoint operates, visual statistic across web application and sites (see screenshot):

There are several free tools to manage large and small SharePoint farms with the review published on SharePointReview site: http://tinyurl.com/9p6j7e. One of the good tools is SharePoint Analyzer from Bamboo solution which provides flexibility to monitor status and diagnose errors.

To diagnose ULS logs the “SharePoint ULS Viewer” provides the most powerful features to sort, filter and search across ULS logs in different categories.

Add Central Administration to Trust/Local Zone

Windows 2008 enhances the security of the internet sites and in result Central Administration site does not play nice with the default internet settings – some links of Central Administration sections are hidden. The same behaviour exists when Central Administration site is opened under non-administrative account.
To fix this, navigate to the Internet Explorer Options -> Security Tab and “Central Administration” site to Trust zone (or Intranet Sites).

Manage size of Content DB

SharePoint performs the best on the content databases below 100GB. This is not a true limitation but rather a recommendation. SQL Server databases have been scaling far beyond 100GB for years now. Practically speaking, the recommendation is based primarily on two significant factors:
1) Service Level Agreement (SLA) requirements for a given organization may dictate that backup operations for the SharePoint databases must be executable in a limited amount of time. The size of the content databases will have a direct impact on how long it takes to execute that backup.
2) The storage subsystem must be robust enough to handle the disk I/O requirements of the SharePoint solution that it serves.
So, monitor how much database grows and create new database content after such threshold. The best way to achieve this is setting alerts via DBA.

Set SQL TempDB Data Files

It is a product team-recommended practice that the number and size of data files allocated for the SQL TempDB Data Files should be equal to the number and size of core CPUs presented on the SQL Server machine. Each data file should be equal in size. Optimal TempDB data file sizes can be calculated using the following formula:

[MAX DB SIZE (KB)] X [.25] / [# CORES] = DATA FILE SIZE (KB)

So, for the server with two quad-core CPUs and the 500 GB content DB there will be 8 files with 15 GB size per temp data file.

If possible, separate each data file to separate logical unit consisting of unique physical disk spindles

Maintain SQL Database

SharePoint databases are usually big, very big, so maintaining databases in primary task to provide the good performance (http://technet.microsoft.com/en-us/library/cc262731.aspx) Consider the following tasks:

• Checking database integrity.
• Defragmenting indexes by either reorganizing them or rebuilding them.
• Setting the fill factor for a server.
• Shrinking databases to recover unused disk space.

Create SQL Maintenance plan to schedule those operation being run automatically.

Manage security and permissions

For each site collection, there is a limited number of security principals (users and groups) that can be applied – 2000 per Web site (limitation of ACL). Use Active Directory security groups and SharePoint groups to manage access, instead of adding users individually. The more fine-grained permissions are applied, the more difficult to track who has access to what. Moreover, fine-grained permissions can affect performance because additional security checks must be performed for each item to which they are applied.

Remove unused and “ghost” users

During farm installation, configuring or migrating, SharePoint farm is usually end up with number of test users or permissions that were used for test reasons, or “zombifies” users – which survived migration and not assigned to nobody. It’s important to remove all these users and check  the permissions to lower the chance of security breach.
There are several tools that address current task – Access Checker, SharePoint SUSHI and “Deliver Point” which provide the best functionality to find “dead” users easily and check permissions hierarchy across all site collections and sites.

Plan windows updates

In a server farm environment software updates are not installed automatically, even if the Automatic Updates feature is enabled on Web servers. Windows Update Web site or the Microsoft Update Web site can’t be used for software update installation (http://technet.microsoft.com/en-us/library/cc263467.aspx). In this case planning of updates across SharePoint farm boxes is required. Recommendation is to test all updates properly on testing/staging environment with existed applications before propagating updates to production environment.

Adopt farm to number of users

If the environment serves approximately 5000 or more users, consider deploying a minimum of three front-end Web servers, or the number of front-end Web servers that are required to provide appropriate capacity plus one more. That way, when one front-end Web server is experiencing occasional high load, load balancers can route the traffic to other servers. In the case when there is only one remaining front-end Web server, this can cause a cascading outage in which the extra traffic that affected the first front-end Web server is transferred to the second front-end Web server, which brings it down too. Having an extra front-end Web server helps the farm to consume such loads and provide more performance and stability in the farm during such situations. Additionally, consider dedicating front-end Web servers to be configured for crawling reasons only. There front-end Web servers should be physical servers, not virtual.

Optimize index server

SharePoint crawls data incrementally, and index is provisioned the same way – by small portions. Usually new crawled data become available in 3-30 second. If new added file is not discoverable in such timeframe, it means that Index Server suffers from performance issues. Use USL logs and performance counters to investigate what is wrong. In virtualized environment use physical HDD or move Index Role to physical box.

Summary

Installing and configuring SharePoint farms never been a trivial task and usually characterized with number of different issues, which could lead to the reinstalling the farms from the scratch several times. Having proper plan and recommendation for the major milestones in the configuration provides benefits to have work done from the first attempt, and end up with the scalable and reliable environment prepared for the further extensibility.

Post Scriptum

I’d like to thank Darren Neimke, Jeremy Thake, Alex Meleta for their notes and recommendation regarding several chapters, and especially to Eric Shupps for noticing several errors and constructive criticism.  Special thanks to Neville Mehta for the inspiration to create and finish this whitepaper.