Using a host header as a SharePoint site path

Problem

By default, SharePoint uses the name of the server as the root URL address.

For example, if the server host name is 'usweb1019', your SharePoint URL address will start with 'http://usweb1019/xxxxxx'. I'd like to use a friendly name. Even still if we have to migrate or upgrade to new hardware, I would like the URL to the main site to stay the same.

Solution

The solution is to use a host header, however there are several configurations to change in order to make this work. For a smooth configuration change, it is important to put these steps in the proper sequence.

Step #A

Always, always, always...backup your systems. The most critical component to backup (and to know how to restore) is the SharePoint SQL databases.

Step #B

Always, always, always...rehearse this procedure on test or development systems before running on production.

The cookbook overview is as follows:

1. Add a CNAME in DNS.
2. Add a host header in IIS
3. Add the new path to your Excel Services list of trusted paths.
4. Change the Public URL of the Virtual Directory in Alternate Access Mappings.
5. Reset the web server.
6. Install the SharePoint Administrative Toolkit and run 'updatealert' from the stsadm utility.
7. Delete your crawled content in Search settings and start a new full search crawl.
8. Test your system.

Now for the step-by-step instructions.

In this example, we will change the URL path users will use to "http://portal". You can use anything you like. The hostname of the SharePoint server is 'jazz-moss07'. The desired host header name is 'portal'.

1) Add a CNAME DNS entry to your current SharePoint root. (You may need your DNS system administrator to do this for you.) You can also (optionally) map to the IP address instead of the hostname of the server.


Completed DNS entry

2) In IIS on the SharePoint server, find the virtual directory that maps to the main SharePoint site (not the Central Admin or SSP sites). If you kept the default options it will say "SharePoint - 80".

• Right click on the virtual directory and select "Properties".
• In the "HTTP Headers" (tab), click "Add".
• Enter the desired header name that was used in the DNS setup (Step #1).

3) Update the Excel Services Trusted Location settings. (If you are not using Excel Services you can skip this step). Add any needed entries. This can be found in SharePoint Central Administration --> SharedServices --> Excel Services Settings --> Trusted File Locations



4) Change the Public URL of the Virtual Directory in Alternate Access
Mappings.

• Open SharePoint Central Administration
• Open "Operations".
• Under "Global Configuration", click "Alternate access mappings".
  
  
  
  
• Note the existing entries. Take a shot and/or write down the existing entries in case you have to reverse the procedure. Click "Edit Public URLs".
  
  
  
  
• Make sure the "Alternate Access Mapping Collection" is pointed to your content Virtual Directory.
• Change the "Default" to the new Host Header name.
  
  
  
  
• Below is what the new entry will look like:

5) Reset the web server. (From the command line on the SharePoint server, type "IISRESET" and press enter.

6) Install the SharePoint Administrative Toolkit from Microsoft for your operating system. It is available from this web page: http://technet.microsoft.com/en-us/library/cc508851.aspx, After installing, this will add a new option to the stsadm.exe utility called "updatealert". The syntax is as follows:

stsadm -o updateAlert -url -oldUrl

In my case, I entered:

stsadm -o updateAlert -url http://portal -oldUrl http://jazz-moss07


7) Delete your crawled content and start a new full search crawl.

Back in SharePoint Central Administration, Shared Services.

• Under the "Search" section, click "Search settings".
• Under "Crawling" in the left navigation area, click "Reset all crawled content".
• Then click "Content sources and crawl scheduled"
  
  
  
  
• Hold the mouse over "Local Office SharePoint Server sites" until you see the dropdown arrow. Click on the arrow, then select "Start Full Crawl".
  
  

8) Test the new host header URL and all server functions.
NOTE: If for some reason, you need to revert back to the way it was, the critical steps would be to reverse the entries made in Step #4 and Step #6 above, then follow the procedure in Step #7 for resetting and starting the crawl again.

Next Steps

• Return to MSSharepointTips to read about other topics and ideas.
• Check out MSSQLTips.com for great information about Microsoft SQL Server.

Reference:

http://www.mssharepointtips.com/tip.asp?id=929&page=1

SharePoint 2010/2013 Health Checking and Monitoring

A. SPDOCKIT :

I have lately tested another SharePoint farm reporting tool SPDockit for SharePoint 2010/2013 (SharePoint Documentation Kit) for SharePoint 2007/2010/2013 and have to say it saved at least 2-3 days of my time on a consulting engagement, this tool is impressive and works better than the out of the box health check rules. In my job I often conduct SharePoint farm health-checks and  perform farm audits and honestly SPDocKit does help me immensely in collecting and analyzing SharePoint farm and site data. The tool idea itself is no rocket science, it is simply all about extracting almost every possible piece of information from your SP farm and then presenting them by means of an elegant and interactive dashboard interface. The same information displayed in the dashboard can also be generated and saved as reports in pdf and word formats.

The reports can be used as AS-Built documents, created with speed. The tool has its own set of health check rules that enables you to quickly perform healthcheck on your farm against the SharePoint best practices though in some cases you may find not all the rules and recommendation applicable to your environment. Nevertheless it does explanation or refers to best practices if you are not clear what you should do. Another feature that I love is that you can take a snapshot of your farm configuration/settings, save them in a file and then can compare them with other farms or with the same farm later using them as a baseline for comparison.

It doesn't cost a fortune and priced reasonably ($400-700 /farm or consultant). If you are working for a consulting company then I suggest buying licenses for consultants. For the clients/business farm based licensing would be a better option.

You can download the SPDocKit here and try it for 30 days : Download

(I was able to deliver my engagement by using the trial version, was fully functional with all information available through the dashboard options, the only limitation was the cut-down version of reports generated, nevertheless I used the screenshots of the dashboard screens to populate my reports, we are going to buy the full version for the future.)

B. SPFarmReport:

A free tool that I tested on a farm e where I had to do a quick sp2010 farm (with 5 servers) healthcheck, produced a very detailed and nicely formatted report, however I did find it missed some details, on content databases and application pools. Still a good tool that you can pass it on to admins to provide you with a detailed view of Farm configuration and settings.

http://spsfarmreport.codeplex.com/

C. Out of the Box:

• A nice article that summarizes monitoring using OOTB SP 2010 tools http://www.packtpub.com/article/microsoft-sharepoint-2010-administration-monitoring-and-reporting
• However, you cannot use windows PowerShell to view health report data http://technet.microsoft.com/en-us/library/ee663478.aspx

  

So if you opt to go Out of the Box then you have to leverage SharePoint Health Anayzer.

- To configure the SharePoint health analyzer jobs

1. Run the jobs - http://www.sharepointusecases.com/index.php/2010/10/run-all-sharepoint-2010-health-rules-now/
2. And then ask the System Admin in prod to grab the SharePoint Health Analyzer reports from the central admin

 D. SCOM - System Center Operations Manager

The SharePoint 2010 Products Management Pack (MP) is built to detect, diagnose, and alert on software and hardware incidents discovered by agents installed on SharePoint machines.

1. Health monitoring of SharePoint Server 2010, Project Server 2010, Search Server 2010, and Office Web Apps
2. Monitors Events and Services and alerts when service outages are detected
3. Monitors Performance and warns users when SharePoint performance is at risk
4. Forwards users to up-to-date TechNet knowledge articles

A nice video from Brian farnhill, very nice http://www.screencast.com/users/BrianFarnhill/folders/Default/media/3f9f1d6e-4678-4666-88e6-25765f2a7b64

E. Custom Health-check rules

One more thing that can be done (looks beyond the scope of engagement but for future reference) is creating custom health check rules.

http://www.wictorwilen.se/Post/Custom-Health-Rule-for-SharePoint-2010-that-checks-for-Debug-build-assemblies.aspx

Probably you won’t create the rules, but prefer to wait till they appear on codeplex or as a separate product

Hope it would help

SharePoint Usage Reports
Site usage analytics without page modification. Free trial
Reference:

http://hassansyed.blogspot.in/2011/03/sharepoint-2010-health-checking-and.html

Monitoring SharePoint 2010 – Tutorial

To ensure the availability and reliability of your SharePoint Server 2010 environment, you must actively monitor the physical platform, the operating system, and all important SharePoint Server 2010 services. Preventative maintenance will help you identify potential errors before an error causes problems with the operation of your SharePoint environment. Preventative maintenance combined with disaster recovery planning and regular backups will help minimize problems if they occur. Monitoring your SharePoint environment involves checking for problems with connections, services, server resources, and system resources. You can also set alerts to notify administrators when problems occur. Windows Server and SharePoint Server 2010 provide many monitoring tools and services to ensure that your SharePoint environment is running smoothly.
The following maintenance tasks let you establish criteria for normal behavior of your environment and to detect abnormal activity. It is important to implement these daily maintenance tasks so that you can capture and maintain data about your SharePoint environment, such as usage levels, possible performance bottlenecks, and administrative changes. The following sections describe specific monitoring tasks which then map to the checklists as described below.
1. Diagnostic Logging
The Unified Logging Service (ULS) provides a single, centralized location for logging error and informational messages related to SharePoint Server and SharePoint solutions. Systems administrators have one place to look when they need to troubleshoot an issue or monitor the overall health of the environment.
SharePoint Server 2010 includes improvements that are related to the management of the Unified Logging Service (ULS or Trace Logs) logs and that make it easier for administrators to troubleshoot issues. These are described in the following sections.
2. Event Throttling
Event throttling enables administrators to control the types of event that SharePoint Server log based on the level of severity. The administration of throttling is divided into two sections:
1. Destination
Log entries can be reported in two places. The first is the “Event Log”, which is the standard Windows Event Log. Administrators can use the Windows Event Viewer application to review entries. The second is the ULS or “Trace Log”, a text based log format that is specific to SharePoint Server and is stored on the file system. The default location is C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\LOGS.
2. Category
The event throttling dial can be applied to specific categories which map directly to SharePoint Server functionality. This enables the administrator to increase the logging detail for SharePoint components individually, thereby managing the size of the logs and the amount of information to review.
The default settings for all categories are as follows:
• Event Log: Information
• Trace Log: Medium Level
During normal operation, these settings are an appropriate balance of detail and performance. During substantial reconfiguration of SharePoint Server, during the installation of custom solutions, or when SharePoint Server is experiencing issues, the throttling dial should be turned down. This ensures as much information is available as possible for troubleshooting.
Finally, after completing any troubleshooting, logging can be returned to the default by selecting the “Reset to default” option in the throttling drop-downs. Settings that are not currently configured with the default option will appear in a bold font.
Correlation IDs
Correlation IDs are GUIDs that are assigned to events which occur during the lifecycle of a resource request. This value is surfaced within error messages, the ULS logs, and tools like the Developer Dashboard. This value helps an administrator locate and isolate a specific request across the ULS log, Usage Logging database, and SQL Server Profiler data sets for debugging purposes.
For example, administrators can take the Correlation ID that appears on an error page in their browsers and then rapidly locate any related entries in the ULS logs through a simple search.
Correlation IDs also span machine boundaries. If a request, such as a front-end Web server calling a Web service on an application server, crosses a machine boundary the assigned Correlation ID can provide a complete overview of activities during the life-cycle of the request.
Event Log Flood Protection –
Event Log Flood Protection prevents the “Event Log” from being overwhelmed with many repetitive events. When Event Log Flood Protection is enabled (default), it will start trimming events after the same event is logged five times within two minutes. At this point it suppresses additional entries. After an additional two minutes, it throws a summary event that describes the number of times that the event would have been repeated. An administrator can modify these thresholds.

3. ULS or Trace Logging -
Trace Logs can quickly consume disk space, especially when configured to use the more verbose output settings. To manage this growth, administrators can implement two types of restrictions:
a) Administrators can determine the number of days that log files should be kept. By default this is set to 14 days.
b) Administrators can also place a limitation on the overall disk space that log files can consume. This is disabled by default but provides for an additional layer of protection aimed at preventing excessive disk space consumption.
2. Usage Data and Health Data Collection
In addition to Diagnostic Logging, SharePoint Server 2010 also proactively logs information that is related to the overall health of the farm. As an administrator you can individually select which events are monitored, for example the usage of features, page load times, and search queries.
This functionality both consumes disk space and has a performance overhead. Like Diagnostic Logging, care needs to be taken to manage it appropriately. The following options are available to administrators:
1) Health Data Collection
Health reports are built by taking snapshots of various resources, data, and processes at specific points in time. The number of Timer Jobs to schedule will depend on the number of events that you selected to monitor. The frequency of these jobs can be modified to manage the performance impact.
2) Log Collection Schedule
The Log Collection Schedule Timer Job is responsible for collecting Usage Logs from the various servers in the farm, processing them, and then populating a centralized database from where they can be queried for reporting. Once processed, the logs are deleted from disk, freeing up the space they were consuming. The frequency of this job can be modified to manage the consumption of disk space.
Note:
Everything that is being logged to the Windows Event Viewer and to the SharePoint log files is also being stored in the SharePoint Server 2010 logging database. The logging database is also used by the SharePoint Health Analyzer and by SharePoint usage reporting.
Use the following checklist to implement these features in your daily operations:
4. SharePoint Health Analyzer
SharePoint has a number of features that log and gather detailed statistics about all aspects of the health of the environment. The SharePoint Health Analyzer aggregates all of this data, identifies possible problems, then proactively looks for, and recommends solutions.
Many solutions that it finds will include a “Repair Now” link, which when selected will automatically resolve the problem. Other solutions will link to online help content which is constantly updated with the latest information about the problem.
Like the “Best Practices Analyzers” available for other platforms (such as Microsoft Exchange Server), Health Analyzer includes a set of rules which can be extended by developers and which is continuously compared to the existing settings and metrics drawn from your production environment. Rules are applied across a number of categories, including security, performance, configuration and availability.
5. Timer Jobs
The monitoring features in SharePoint Server 2010 use specific timer jobs to perform monitoring tasks and collect monitoring data. The health and usage data might consist of performance counter data, event log data, timer service data, metrics for site collections and sites, search usage data, or various performance aspects of the Web servers. The system uses this data to create health reports, Web Analytics reports, and administrative reports. The system writes usage and health data to the logging folder and subsequently to the logging database.
You might want to change the schedules that the timer jobs run on to collect data more frequently or less frequently. You might even want to disable jobs that collect data if you are not interested in them. You can perform the following tasks on timer jobs:
• Modify the schedule that the timer job runs on.
• Run timer jobs immediately.
• Enable or disable timer jobs.
• View timer job status. You can view currently scheduled jobs, failed jobs, currently running jobs, and a complete timer job history.
6. Web Analytics
The reports that the Web Analytics functionality in SharePoint Server generates provide detailed insight into how your SharePoint environment is being used, and how well it’s performing. Administrators should become familiar with these reports and how they can create their own (directly in the browser) to plan future capacity and to produce benchmarks to compare with future farm configurations.
All of these reports can be used to help you decide if the current architecture remains “fit for purpose,” meaning that it meets the desired service levels.
The reports are broken down into three categories and can be reviewed based on Web Application, Site Collection, Site and Search Service.

Reference:

http://www.learningsharepoint.com/2010/10/16/monitoring-sharepoint-2010-%E2%80%93-tutorial/

Document Set Feature in SharePoint 2010

In this article we will be seeing how to create Document Set in SharePoint 2010.

Document Set is a new feature introduced in SharePoint 2010 as part of document management. Document set helps to manage group of documents as a single entity. Here we will be seeing how to create document set through UI in SharePoint 2010.

Steps Involved:

1. Go to Site Actions => Site Settings => Site Collection Administration =>Site Collection Features.

2. Activate the feature "Document Sets".



3. Go to the document library.

4. In the Ribbon interface go to Library Tools => Library => Library Settings => Advance Settings.

5. Check Yes for Allow management of content types.



6. Click OK.

7. In the Content Types section click "Add from existing site content types".



8. Add Document Set Content type, click Ok.



9. In the ribbon interface go to New Document =>Document Set.



10. Enter the Name and Description, click OK.



11. In the document set upload a document, it looks like the following.



12. You can manage all your documents by creating the document sets.

Reference:

http://www.c-sharpcorner.com/uploadfile/anavijai/document-set-feature-in-sharepoint-2010/
 

How to implement reusable workflows on multiple lists in SharePoint 2010

Problem

In SharePoint, a List is one of the most usual ways to store data. We can have multiple lists using the same kind of data (i.e. the Finance and Sales department lists could share the same kind of employee data -- name, address, experience in years and experience level). Now in such a scenario, what if one wants to implement a single centralized workflow which would apply the same automation process to both lists?

Solution

For such a scenario, SharePoint 2010 has introduced a new kind of workflow which is called a "Reusable Workflow". One use of this kind of workflow is to create it and attach it to different lists. This would be created on a content type. So it could be attached to only the lists which implement the same content type on which the reusable workflow is created.

Let us start by creating a content type. Create a content type similar to what is shown in image (below) and name it "EmployeeContentType". Also create two lists. One named "Sales" and the other named "Finance", both using the same content type.



Now open the web application in SharePoint Designer 2010 and click on workflows. On the top ribbon, click on reusable workflow.




Provide a name to the workflow and select the content type on which the workflow should be created. In our case it is "EmployeeContentType".



Now we have added a simple workflow which will update the employee experience level field according to the years of experience of employee.



Save and Publish it. Now for attaching it to multiple lists, you need to check with which list the workflow could be attached? To do so, click "Associate to List" on the top of the ribbon of SharePoint Designer. At the back end, a web service will fetch the list depending upon the content type applied to the list. In our case there are two lists "Sales" and "Finance". Click on "Sales".



A window will appear which would be similar to an out of the box workflow creation window. Here we need to take care of 4 things:
1) Select the same content type on which the workflow is created -- which in our case is "EmployeeContentType".
2) Select the name of the reusable workflow (which in our case is "EmployeeWF").
3) Provide a unique and meaningful name to the workflow for identification.
44) Configure the start options of the workflow as required.




After performing the above steps, create the workflow. Now we have a sales list with some data.



Now to trigger the workflow, one can edit the items and save it -- accordingly the workflow will update the experience level field values.



Perform the steps for associating the workflow to the finance list until updating the values just like we did in the sales list.



Now the finance list will share the same kind of workflow and values updated accordingly.

Next Steps

• Use a reusable workflow, to create a similar workflow for multiple list.
• Use it to reduce redundancy as well as to maintain a single, centralized workflow
• Return to MSSharepointTips to read about other topics and ideas.
• Check out MSSQLTips.com for great information about Microsoft SQL Server.

Reference:

http://www.mssharepointtips.com/tip.asp?id=1095

Monitoring features of SharePoint 2010

The monitoring features in Microsoft SharePoint Server 2010 help you to understand how the SharePoint Server 2010 system is running, analyze and repair problems, and view metrics for the sites. Monitoring the SharePoint Server 2010 environment includes the following tasks:

• Configuring the various aspects of monitoring to suit business needs.
• Monitoring the environment and resolving any problems that might arise.
• Viewing reports and logs of the environment activity.

Regular performance tests

SharePoint Health Analyzer checks for potential configuration, performance, and usage problems in SharePoint Server 2010. It runs predefined health rules against servers in the farm and returns a status that tells you the outcome of the test.

Receive auto alerts

SharePoint Health Analyzer also creates an alert in the Health Analyzer Reports list in Central Administration. You can click an alert to view more information about the problem and see steps to resolve the problem.

Configuring monitoring

SharePoint Server 2010 comes installed with default settings for its monitoring features. However, you might want to change some of these settings to better suit the business needs. The aspects that you might change configuration settings for include diagnostic logging and health and usage data collection.

Diagnostic logging

SharePoint Server 2010 collects data in the diagnostic log that can be useful in troubleshooting. The default settings are sufficient for most situations, but depending upon the business needs and lifecycle of the farm, you might want to change these settings. For example, if you are deploying a new feature or making large-scale changes to the environment, you might want to change the logging level to either a more verbose level, to capture as much data about the state of the system during the changes, or to a lower level to reduce the size of the log and the resources needed to log the data.

The SharePoint Server 2010 environment might require configuration of the diagnostic loggings settings after initial deployment or upgrade and possibly throughout the system's life cycle. The guidelines in the following list can help you form best practices for the specific environment.

• Change the drive that logging writes to. By default, diagnostic logging is configured to write logs to the same drive and partition that SharePoint Server 2010 was installed on. Because diagnostic logging can use lots of drive space and writing to the logs can affect drive performance, you should configure logging to write to a drive that is different from the drive on which SharePoint Server 2010 was installed. You should also consider the connection speed to the drive that logs are written to. If verbose-level logging is configured, lots of log data is recorded. Therefore, a slow connection might result in poor log performance.
   
• Restrict log disk space usage. By default, the amount of disk space that diagnostic logging can use is not limited. Therefore, limit the disk space that logging uses to make sure that the disk does not fill up, especially if you configure logging to write verbose-level events. When the disk restriction is used up, the oldest logs are removed and new logging data information is recorded.
  Use the Verbose setting sparingly. You can configure diagnostic logging to record verbose-level events. This means that the system will log every action that SharePoint Server 2010 takes. Verbose-level logging can quickly use drive space and affect drive and server performance. You can use verbose-level logging to record a greater level of detail when you are making critical changes and then re-configure logging to record only higher-level events after you make the change.
   
• Regularly back up logs. The diagnostic logs contain important data. Therefore, back them up regularly to make sure that this data is preserved. When you restrict log drive space usage, or if you keep logs for only a few days, log files are automatically deleted, starting with the oldest files first, when the threshold is met.
  Enable event log flooding protection. Enabling this setting configures the system to detect repeating events in the Windows event log. When the same event is logged repeatedly, the repeating events are detected and suppressed until conditions return to a typical state.

Health and usage data collection

The monitoring features in SharePoint Server 2010 use specific timer jobs to perform monitoring tasks and collect monitoring data. The health and usage data might consist of performance counter data, event log data, timer service data, metrics for site collections and sites, search usage data, or various performance aspects of the Web servers. The system uses this data to create health reports, Web Analysis reports, and administrative reports. The system writes usage and health data to the logging folder and to the logging database.

A timer job is a trigger to start to run a specific Windows service for one of the SharePoint 2010 products. It contains a definition of the service to run and specifies how frequently the service should be started. The Windows SharePoint Services Timer v4 service (SPTimerV4) runs timer jobs. Many features in SharePoint 2010 products rely on timer jobs to run services according to a schedule.

You might want to change the schedules that the timer jobs run on to collect data more frequently or less frequently. You might even want to disable jobs that collect data that you are not interested in. You can perform the following tasks on timer jobs:

• Modify the schedule that the timer job runs on.
• Run timer jobs immediately.
• Enable or disable timer jobs.
• View timer job status. You can view currently scheduled jobs, failed jobs, currently running jobs, and a complete timer job history.

Monitoring the farm and resolving problems by using SharePoint Health Analyzer

SharePoint Server 2010 includes a new, integrated health analysis tool that is named SharePoint Health Analyzer that enables you to check for potential configuration, performance, and usage problems. SharePoint Health Analyzer runs predefined health rules against servers in the farm. A health rule runs a test and returns a status that tells you the outcome of the test. When any rule fails, the status is written to the Health Reports list in SharePoint Server 2010 and to the Windows Event log. The SharePoint Health Analyzer also creates an alert in the Health Analyzer Reports list on the Review problems and solutions page in Central Administration. You can click an alert to view more information about the problem and see steps to resolve the problem. You can also open the rule that raised the alert and change its settings.

Like all SharePoint Server 2010 lists, you can edit Health Analyzer Reports list items, create custom views, export the list items into Microsoft Excel, subscribe to the RSS feed for the list, and many other tasks. Each health rule falls in one of the following categories: Security, Performance, Configuration, or Availability.

A health rule can be run on a defined schedule or on an impromptu basis. All health rules are available through Central Administration, on the Monitoring page, for either immediate or scheduled execution.

Farm administrators can configure specific health rules to do the following:

• Enable or disable rules.
• Configure rules to run on a predefined schedule.
• Define the scope where the rules run.
• Receive e-mail alerts when problems are found.
• Run rules an impromptu basis.

View and use reports

SharePoint Server 2010 can be configured to collect data and create reports about server status and site use. You perform the following using reporting:

• View administrative reports, such as search reports.
• Create and review Information Management Policy Usage reports.
• View health reports that include slowest pages and top active pages.
• View Web Analytics reports that include Web site traffic reports, search query reports, and customized reports.

Reference:

http://www.c-sharpcorner.com/uploadfile/Roji.Joy/monitoring-features-of-sharepoint-2010/

Health Analyzer in SharePoint 2010

Problem

As a SharePoint Administrator you always wanted to have something in place which alerts you about the running issues or potential problems in your farm. SharePoint 2010 has come up with an 'out of the box' Health Analyzer feature which alerts you about the potential problems, and the locations where they occurred, the cause and how to resolve these issues. Let's explore it more.

Solution

SharePoint 2010 has a new feature called the Health Analyzer which regularly checks (on a defined schedule) for potential security, performance, configuration and usage related problems. The Health Analyzer reports the issue with a detailed explanation, where it exists and what can be done to get rid of that issue, etc. In some cases the Health Analyzer itself can repair the issue and inform the SharePoint administrator about it. For example there might be a case when database indices are highly fragmented or statistics are outdated or a database has large amounts of unused space. In those cases, you can set Health Analyzer to automatically repair those issues when it finds them.
Out of the box, SharePoint 2010 has 60+ health rule definitions (categorized under four different categories: Security, Performance, Configuration and Availability) which dictate what to monitor, where to monitor, severity of the issue, etc.
The Health Analyzer runs these rules on their defined schedules (using timer jobs) and reports the problems if there are any (and also stores the data to the logging folder and to the logging database as well for future reference).
You can view these built-in health rule definitions by going to the Monitoring link on the left side of Central Administration and clicking on the "Review rule definitions" link under the Health Analyzer which will bring open a screen like this:



By default all the health rule definitions are enabled and the schedule has been defined, though you can change these default settings as you can see below.
You can change:

• The scope which tells where the rule will run.
• The schedule to run it hourly, daily, weekly, monthly or on demand.
• The setting for enabling/disabling it.
• Repair the problem automatically.
• The version number of health rule change (rule definitions are stored as SharePoint list).

Please note, the SharePoint Health Analyzer health rule definitions are farm wide settings which work on a predefined schedule set by Administrators. A number of health rules are shipped with SharePoint, though you can create and deploy your own developed/customized health rules to SharePoint, for more information click here.


 

Getting started with Health Analyzer

When you launch SharePoint 2010 Central Administration, a bar appears just below the ribbon space indicating the Health Analyzer has found some issues, if there are any. You can click on the "View these issues" link to get the details of those reported issues.

Not only that, you can even view the Health Analyzer report (and its archive) on demand by going to the Monitoring link on the left side of Central Administration and clicking on the "Review problems and solutions" link under Health Analyzer as shown below:

Clicking on the above links brings the report as shown below. It shows all the problems reported/detected so far categorized under Security, Performance, Configuration and Availability. It also shows the name of the server where it exists, failing services and when it was last modified.


 

Clicking on any of these above links brings the details about the problem (as shown below). As you can see, it gives you the severity of the problem, a detail explanation of what this problem is about, and how it can be resolved. You can also re-analyze the problem instantly from this screen (after fixing it) to see if it still exists and you can also set the alert (email or SMS) to be sent immediately or on defined schedule to SharePoint administrators. At the end of this screen you will notice the name of the server and service where this problem was reported.

Next Steps

• Review Configure SharePoint Health Analyzer timer jobs article on technet.
• Review Developing and Deploying a Custom Health Rule article on technet.
• Check out Best Practices for SharePoint Content Databases in SQL Server
• Learn how to write a Custom SharePoint Timer Job
  
• Review my other tips on SharePoint.

Reference:

http://www.mssharepointtips.com/tip.asp?id=1128&page=4