I use SharePoint’s ULS logs almost daily when supporting and administering SharePoint (2007 and 2010 for that matter).  Let’s look at what it is, and how it can help you troubleshoot issues in SharePoint 2010.

What is this “ULS Logging”?

Like most (but not all) features in SharePoint 2010, logging did get an upgrade from 3.0 / 2007.  First of all, what is ULS?  It stands for Unified Logging Service (ULS).  It is the engine that handles creating a detailed trace output of all of the events that occur in SharePoint.  It is dependent on the Windows service “SharePoint 2010 Tracing”.  By default, SharePoint creates these log files in the file system in the “14 hive”:

C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\LOGS

These log files are written by SharePoint in real-time and contain information regarding event logging per its configuration in Central Administration. 

New for 2010

SharePoint 2010 introduced some new features with regards to trace logs.  Here are some of the highlights.

Correlation IDs

One big struggle with the ULS logs is that they were very hard to try and find where a specific error occurred.  You might have known when it happened, but it was very difficult to find the correlating specific error in the actual log.  Microsoft introduced the concept of a Correlation ID.  The way this works is that every event in SharePoint is given a unique GUID string.  Related events are grouped together by the same Correlation ID.  So for a given event, all of the actions that take place have the same correlation ID.  This way, you are able to very easily find the grouping of events that relate to each other.  When an exception occurs, the Correlation ID is shown.  Once you have that ID, that is when you dive into the ULS logs.  We’ll go into detail on that shortly.

Event Throttling

In 2007, the interface used to configure event throttling for events wasn’t all that great.  You had some flexibility to set the severity level logged by category, but it was a little clunky:

In 2010, it has been changed significantly to help make modifications easier, especially being able to determine what level of logging has been set for which categories.  You can also easily reset all modified settings back to default.  Typically these options are modified when you are troubleshooting an issue on a specific component.  Here’s what the new UI looks like:

Event Log Flood Protection

This is a new option for 2010.  This new feature, as it’s name implies, prevents the event log from being flooded with duplicated events.  This is just good practice to enable.

Trace Log Configuration

Here’s how the settings looked in 2007:

The trace log settings also got an upgrade in 2010. Here’s the same section in 2010.  They really got smart and gave us some options to be able to prevent the server from filling up with logs.  As I understand it, after the number of days to store log files has expired, it prunes the logs from day 1.  The next day it will prune day 2 and so on so that there will always only be 14 days worth of log files.  You also have a new option to be able to restrict the log files by file size as well.

Microsoft has some best practices for configuring these diagnostic logging settings on TechNet.  Now let’s take a look at how to use the ULS log files for troubleshooting.

ULS Usage

How to Configure the Tracing Settings

For the sake of this post, we are focusing on SharePoint 2010 so all steps are specific to the 2010 interface.  To configure ULS logging settings, you have to access Central Administration.  Under Monitoring, click Configure diagnostic logging. 

How to View the ULS Logs

The ULS log files are text files that SharePoint creates in the convention <servername-yyyymmdd-time>.log.  You could, in theory, use notepad to read the ULS logs.  I would advise against that if you want to retain your sanity.  Microsoft has provided (along with at least one on Codeplex) a viewer to look at the ULS log available here.  Between the two, I personally like one from Microsoft because it has more features and I just think is better.  In the viewer, you can either watch the ULS logs real time, or open a previous log file.

Troubleshooting with the ULS Logs

So when would you actually use all this?  Well, I’m sure in your life using SharePoint you will eventually encounter an error (sorry Microsoft, no one’s perfect).  When you see that dreaded error message, fret not!  If you’re not already, you’re going to have to remote on the SharePoint server.  Now open your trusty ULS log viewer.  You have two choices here to find the exact error in the ULS logs:

1. Hopefully you will be able to reproduce the error at will.  So open the logs in a real time view, and find the error.
2. Or, you can’t reproduce at will, so you will have to do a little hunting.  If you know about when it occurred, you can open a log file and search.

Let’s look at the ULS log viewer.  To open the logs in real time, click File –> Open From –> ULS. 

On the next dialog, choose the default option “Use ULS feed from default log-file directory”, then click Ok. Then watch the fun!  If you want to see a particular log, it’s just as easy.  Click File –> Open From –> File.  It defaults to the LOGS directory, and browse the list to find the ULS log file you want.  You can see the date/time, process, product and category, severity level, Correlation (remember that?) and a detailed message of each event. 

One of the cooler features that makes it easier to find the correlation ID is the correlation tree.  Click the button on the toolbar in the top right corner (Toggle Correlation Tree) which will open on the left.  Change the drop down to Correlation, and find the ID from the error.

You can of course search and find certain text if you’re looking for something specific.  One thing I’ve done a lot in the past is when troubleshooting the User Profile Service (and who hasn’t?).  You can filter the view by category like this:

This will only show events that relate to the User Profile Service.  When you provision a User Profile Service, there are a known certain events that you should see, and this makes it very easy to see and watch.  I encourage you to check out other features as well like the Smart Highlighting.  You can also change the level of events that are displayed. 

In another blog post, we’ll look at a related feature, the SharePoint Health Analyzer!  I hope this has been helpful, and encourages you to check out your ULS logs!