It is a flue season. Is you SharePoint farm “healthy”? SharePoint Health check

The best scenario when you can say “ I know my SharePoint Farm” is when you actually just set it up, not months after. Giving your environment a health check is a good idea, especially in environments that do not have on staff people 100% dedicated to SharePoint.

This week I was at a client to do exactly this, the “health check” of their farm. There were no complains about the performance or bugs, but because there was no SharePoint monitoring or maintenance set up they thought it would be a good idea to take advantage of our “Health Check” offer. The company also wanted us, based on the findings, to give them recommendations on how they can better use and utilize SharePoint features.

Here are some notes from the “Health Check”, and pointers on what to look for during the process if you decide to do it your self:

Infrastructure Architecture.

analysis and documentation of the existing physical structure of the farm can help to determine at a glance where possible performance issues might happen as well as points of failure.

Infrastructure architecture includes, but not limited to:

1. Hardware configuration
2. Topology setup for the farm
3. Server roles.
4. SharePoint Server and SQL server storage.
5. Patching and Updates level on all servers
6. Virtualization
7. Event logs on all servers in the farm

Analysis of this will also greatly help in evaluation of the existing backup and D/R strategy as well.

Logical farm setup:

IIS setup on all WFEs

• Application pools
• Web applications
• Hostheaders
• logs location

SharePoint Architecture.

General farm settings

• Incoming, Outgoing eMail settings
• Quota Templates.
• Web Applications and their content databases
• Web Application Policies
• Managed Paths
• AntiVirus

Shared Service Provider

• User Profiles
  • Schedule
  • Source
• Search
  • Content sources
  • Rules
  • Schedules
  • errors log
  • Security settings on the content sources for the crawl account

Security

• Administrative and Service Accounts
  • app pools
  • web apps
  • Search content access accounts
• SQL
  • SQL Database accounts

Site Collections

• Site Directory Settings
• Site Collection Features
• Portal Site Connection
• Site Collection Audit Settings
• Output Page Caching
• Security
  • Brocken inheritance
  • Security groups management

As the result of the discovery process, besides the documentation of the existing environment along with all other findings, there should be a good recommendations document produced with information on how to and best practices.

For example: event viewer application log was full of Even ID 6432, 7076, 6398 which was indicative of necessity of the following patch http://support.microsoft.com/?id=946517, along with this we have provided the whole guide on application of patches and their verification process.

There were no incremental backups on the farm, instead there were nightly full, granular (Third Party) backups that sometimes would take more than 12 hours to finish up and would have to be interrupted. And no OS or file level back ups was happening as well :-(

There were app pools in the IIS that were not used, some app pools that were used should not have been created in the first place. SQL server and WFE all had farms admin account as local admin account, number of other “sharepoint” logins were created on the SQL side, but in reality were not used.

Part of the Findings and Recommendations also outlined some of the general performance monitoring for SharePoint server, including SharePoint and SQL specific performance counters and what to look for.

I’ll post some of the best practices and recommendations at some point, but now I’m back to 2010 content :-)

Enjoy.

Technorati Tags: SharePoint health check