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.
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.
SharePoint 2010 introduced some new features with regards to trace logs. Here are some of the highlights.
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.
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:
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.
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.
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.
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.
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:
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!
Husain,If you look in Central Admin, is the logging level default for everything (nothing bolded)? If the logging level is turned up on one of the web-based components, that would explain part of it. Have you looked in the logs to see what they are logging? What services are running on the WFEs that the app server is not?Doug
Doug,Thank you for your reply.Appreciate your helpFollowing are the answers to your question regarding the logging and services in the farmCurrent Setting: In Central Admin --> the logging level is set at default for everything (nothing bolded)Can't open the log files - Have you looked in the logs to see what they are logging? What services are running on the WFEs that the app server is not?Services running on WFE (these services are running on App Server also)Microsoft SharePoint Foundation Incoming E-Mail Microsoft SharePoint Foundation Web Application Microsoft SharePoint Foundation Workflow Timer Service Search Query and Site Settings Service SharePoint Server Search Running on WFE onlyMicrosoft SharePoint Foundation Sandboxed Code Service Thank YouHusain
hi..its really useful article.i eventually encounter an error while using sharepoint. now i understood the uls usage and troubleshooting with uls logs.
Hello Team,The SharePoint Log files on Web servers are growing large - size about 900MB to 1GB +But Log files on Application Server is normal.Please can you help us to idendity what config change might be causing the SharePoint Logs on WFE Server grow large.Thank you appreciate your helpHusain
The complementary paper includes over 12 years of research, recent survey results, and CRM turnaround success stories.
This 60-second assessment is designed to evaluate your organization's collaboration readiness.
Learn how you rank compared to organizations typically in years 1 to 5 of implementation - and which areas to focus on to improve.
This is a sandbox solution which can be activated per site collection to allow you to easily collect feedback from users into a custom Feedback list.
Whether you are upgrading to SharePoint Online, 2010, 2013 or the latest 2016, this checklist contains everything you need to know for a successful transition.