Create a Subscription

The Event Viewer allows you to subscribe to events on multiple servers and attach tasks such as sending an e-mail or running a program in response to particular events. Here are the steps to ensuring you are notified of any Critical or Error events in the logs on your SharePoint servers. The first step is to create a new subscription, as shown in Figure 7-4.

Next, name your subscription and where the details of the subscription trigger events will be written to. You can also at this point identify multiple source computers for your subscription. Computers that will be sending events to each other must have the proper authentication in place first. Do this by adding the computer account for your “primary” server to the Administrators group on all servers from which you wish to collect events. This may require a reboot. The primary server is just the one from which you manage the subscription, so logically it would be the one from which you access SharePoint Central Administration. The OK button will remain inactive until you select at least one computer (Figure 7-5).

Next, click the Select Events button, click Edit, and choose the information you want to collect from where. In Figure 7-6 I have chosen Critical, Warning, and Error messages from the Event log for SharePoint in the past 24 hours. You can experiment with more refinement than this to suit your own needs. Figure 7-7 shows the subscription.

Your subscription will start automatically. Details of what it captures will be displayed in the Forwarded Events Log, as shown in Figure 7-8.

You now have a way to consolidate specific events across all your SharePoint servers. For more detail you can go here: http://technet.microsoft.com/en-us/library/cc749140.aspx. You may not need sophisticated tools like SCOM if this is sufficient for your organization’s needs. The events you subscribe to are a result of recurring errors, because if you could predict everything that was going to go wrong before it happened, you’d be doing more with your life than administering SharePoint. I have used it in the past to alert me to recurrent problems caused by patching procedures that were not followed; you will build up your own profile.

Setting up Tasks: Sending an E-mail Alert

So you have consolidated your events from multiple servers and specified which ones you want to know about. What action do you want Windows to take when they occur? You can ask Windows to run a program, put a message on the screen, or send an e-mail. You can even specify multiple actions. The most common action is to send an e-mail, so I will describe the steps here. To schedule a task for sending out alerts upon the arrival of a subscribed event, start Task Scheduler from Administrative Tools.

On the General tab  (Figure 7-9), name your task and specify under what privileges it will run. I have set mine to run whether I am logged on or not. I am also not running it with the highest privileges. Don’t be tempted to do this in a production environment, as it is always best practice to follow the principle of least privilege and it is unlikely this task needs all the privileges the Administrator (in my case) account has. For additional security, you could use an account with limited privileges just for this purpose.

On the Triggers tab (Figure 7-10), I pressed the New button to bring up this dialog. In it I specified my task to run just before I check it in the morning every day. That way, when the e-mail is sent, it will contain the latest information and I will receive it an hour before I arrive at work at 7 a.m. (Set this to suit your own schedule.) I have also ticked the box that says “Synchronize across all time zones.” This is useful if you want to set this task so it is seen in the morning by your administrators in other countries.

On the Actions tab (Figure 7-11), I pressed the New button to bring up this dialog. Here is where you choose your action. The first drop-down also allows you to display a message or start a program. In this case, specify where to send the e-mail and what SMTP server to use.

On the Conditions tab (Figure 7-12), you have the option to have the computer wake up to send the e-mail; this may be necessary if it has been idle all night. Otherwise, leave the settings here as the default. Other than the trigger, you may want to send the e-mail if the machine has switched to battery power or has had to use a secondary NIC.

On the Settings tab (Figure 7-13), you have options about when and how the alert will run. I set it to retry five times if it fails and to stop if it takes longer than an hour. You can also create one-off tasks that automatically delete after they run. If there is more than one instance of a task, your options are (if the task is already running) to run a new instance in parallel, queue a new instance, or stop the existing one.

Once you have been prompted to enter your administrator password to create the task, you can manually run it to test it (see Figure 7-14). Multiple tasks will alert you as soon as possible to problems with your SharePoint farm. It may be that one person is not monitoring it 24/7, in which case alerts can be set up to be sent to the appropriate person for that time. Some organizations, for example, have some staff only on call outside of normal business hours, so separate alerts can be configured to be sent to the appropriate person depending on the day/time. The nice thing about this functionality is there is a simple, clear graphical interface to let you create and manage these alerts.

Your SharePoint system may generate errors, but sometimes you need to be alerted if the hardware is using too many resources such as memory or processing power. In this case, you want to get the alert because you want to catch the problem before it generates errors at the application level. Your goal, like the binoculars on the Titanic, is always to see the trouble coming from as far off as possible to give you the greatest chance to avoid it.

You can also collect data from multiple servers in what are called data collector sets. I will show you how to set up event subscriptions using them to monitor memory- and performance-related counters.

The Unified Logging Service

The Unified Logging Service (ULS) is the single, centralized location for logging error and informational messages related to SharePoint Server and Solutions. This means you have one place to look when you need to troubleshoot an issue or monitor the overall health of the SharePoint application. It aggregates logs from the following three locations:

• SharePoint trace logs
• Windows Event Log (which I have discussed already)
• SharePoint logging database

The ULS viewer is an excellent way to get a real-time look at your logs. You can download it from http://archive.msdn.microsoft.com/ULSViewer/Release/ProjectReleases.aspx?ReleaseId=3308 and install it on your SharePoint server. Once installed, click Ctrl+U and then OK to see the data being added to your log in real time (Figure 7-24).

Try the Toggle Correlation Tree button. This is the one furthest to the right in the screenshot above. You could use the example correlation ID to trace a series of events inside SharePoint. A specific error may occur a number of times in a big ULS log file, but with the correlation ID you can easily track them. Another good feature is notifications. You can set the notification level for ULS Viewer; by default it will pop up and notify you of a Critical message.

Health Analyzer

This tool is used to automate the monitoring of the configuration of your SharePoint farm. It is clever because it does more than alert you to problems like the Event Viewer; it can fix the problems automatically for you. For example, if the logs are set to verbose and are going to fill up the disk capacity, the Health Analyzer can reset them. This is because each rule is in fact a DLL, a compiled program that can execute script. It runs inside a timer job and so is fully automatic.

You will notice it alerts you when you visit SharePoint Central Administration (Figure 7-25). In this example, it is on a red background because the issues are critical but if there are less serious issues, it’s yellow.

There are over 60 rule definitions, all listed on the Review Rule Definitions page (Figure 7-26) in Health Analyzer. Each once can be scoped to every server on the farm and have a different schedule.

As before, it is configured through rules that can be evaluated hourly, weekly, monthly, or on demand. You can also configure it to send you alerts either by e-mail or SMS text message. Since some of these jobs only run monthly, if you have just set up your farm, you may want to run them all once to see your farm’s initial health. To do this, run the following PowerShell (with thanks to Matthew McDermott for this):

$jobs = Get-SPTimerJob | Where-Object {$_.Title -like "Health Analysis Job*"}
foreach ($job in $jobs)
{
  $job.RunNow()
}

You can also see in Figure 7-26 the ability to manually rerun an individual rule to see if it is now being followed. This will only queue the timer job to run when resources are available, which may not be instant. The Review Problems and Solutions page, accessed under Health Analyzer in the Central Administration Monitoring section (see Figure 7-21) shows any problems your farm may be having.

Timer Jobs

Timer jobs are the clockwork mechanism of SharePoint—the cogs and moving parts of the system. You can monitor them from the Review Job Definitions page, accessed under Timer Jobs in the Central Administration Monitoring section; you can also manually run them to ensure they are working. The Check Job Status Page lets you see the history of when jobs were last run and if they were successful. This can be useful for troubleshooting.

Diagnostic Logging

There are three settings in diagnostic logging you can set for SharePoint.

• Event Throttling
• Event Log Flood Protection
• Trace Log

These are accessed in Configure Diagnostic Logging under Reporting in the Central Administration Monitoring options. Let’s consider each of these settings.