How to Troubleshoot SharePoint Errors – Part 2: Digging into ULS

Home » SharePoint Blog » How to Troubleshoot SharePoint Errors – Part 2: Digging into ULS

In part 1 of the series we looked at a common SharePoint issue (503 service unavailable) and how to troubleshoot using IIS logs. The 503 can be caused by a number of things including patching and other SharePoint maintenance.  In this article we are going to dig into another critical troubleshooting tool for SharePoint administrators – the SharePoint ULS trace logs.  When troubleshooting correlation IDs and pretty much any other SharePoint application error or performance issue you’ll want to take a look at ULD logs.

Let’s start out by looking at how to configure the SharePoint ULS logging via PowerShell and Central Administration.

SharePoint has hundreds of component categories that you can individually configure to record more information in the logs.  One way to take a look at these categories is with Powershell.

As a SharePoint farm administrator with shell access you can type the following in the SharePoint management shell.

Get-SPLogLevel

Get SP Log Level

As you can see you can get very granular based on what SharePoint component you are troubleshooting.

There a several severity levels you can set with the ULS trace level default being medium:

  • Unexpected – these are typically exceptions that indicate a problem
  • Monitorable- these are errors that may not explicitly break functionality but should be monitored over time
  • High – these are high level changes in configurations, starts and stops of services
  • Medium – these will capture succeeding or failing out of the box functionality like creating site or list assets or enabling features
  • Verbose – these are typically used by developers to dig into code issues and should not be left on for long periods of time
  • VerboseEx – these are the most verbose and can be useful for debugging tracing in code such as loops, database calls, etc

If we wanted to make the trace logs more verbose for a specific SharePoint component you have a couple options – PowerShell or Central administration.

An example with PowerShell:

Set-SPLogLevel -Identity “SharePoint Foundation:Monitoring” -TraceSeverity Verbose

To double check that our change took effect we can run:

Get-SPLogLevel -Identity “SharePoint Foundation:Monitoring”

Get SP Log Level Identity

You’ll also notice the EventSev property.  This controls the verbosity of events written to the Windows Application event log.

To set all category severity levels back to the default values you can run:

Clear-SPLogLevel

Now let’s hop on over to Central Administration and look at another way of configuring your ULS Logging.  If you open up Central Administration and click on Monitoring > Configuration Diagnostic Logging you’ll see the other way to configure ULS Logging

Central Administration Diagnostic Logging

You would just select the category check box and at the bottom select the Least critical event to report to the event/trace logs.  Here is also where you configure the ULS log location on disk and how many days of data to keep on the farm servers:

Central Administration Diagnostic Logging Options

If we hop on over to the folder path of the ULS logs you’ll find several log files with the naming convention of Server name – date.  Let’s sort by newest first and open up the latest using notepad.  You should see a table with many lines and columns

ULS logs sorted by newest in notepad

Notepad is a quick way to take a look at these log files, but the best practice is to use a utility like ULSViewer which gives you the ability to sort and filter these massive files.  You can download this directly from Microsoft here.  Once downloaded you can open up the application and choose File > open from > ULS and get real time log parsing.  This tool is a must have for all SharePoint administrators.

ULS logs in ULS Viewer

If an end users receives an error that includes a Correlation ID you can use this tool to find that correlation ID and figure out what the problem really is.  You can also use this tool to search for the URL the user was hitting at the time of the error.   It is extremely useful.  There are several ways to filter your view of these logs based on any of the fields.  One of my favorites is to right click on an interesting line item > Filter by this item then select the fields to filter on.

Restrict by Entry

Instead of manually digging through log files you can also search the logs using PowerShell.  You can export relevant log entries based on a correlation ID.  Every transaction within SharePoint is assigned a unique GUID called the correlation ID that allow you to drill down into what exactly was happening at the initiation of the process through the end.  To export all events with a specific correlation ID to a new files you can run:

Merge-SPLogFile –Path “E:\error.log” –Correlation “9a376f9e-ac5a-e094-c353-dcba72ad6c9e”

Merge-SPLogFile is helpful if your SharePoint farm has multiple servers.  It will go grab all events with this correlation ID from every server in the farm and put a copy into this new file.

If you have a very large farm we recommend implementing an enterprise log aggregation solution such as Splunk.  This allows you to import IIS, Windows events, and SharePoint logs all into one place for troubleshooting and trend analysis.  It is very powerful and helpful for larger SharePoint deployments.

I hope you found this helpful and good luck fixing SharePoint!

Contact Us

Let’s discuss your unique needs!

2018-06-15T09:12:59+00:00 June 11th, 2018|

Leave A Comment