Each server in a SharePoint farm maintains a series of diagnostics logs known as ULS logs, which are contained by default in %ProgramFiles%\Common Files\Microsoft Shared\Web Server Extensions\15\Logs and are saved by default in 30-minute increments.
NOTE ULS LOGGING FORMAT
ULS log files are in standard *.txt format. ULS log files are named in the format servernameyyyymmdd-hhhh where the hour indicated (in 24-hour format) indicates the beginning time of the log.
These logs are not available to be viewed through Central Administration, but can be viewed by using the following:
- A text editor such as Notepad
- Windows PowerShell
- Developer Dashboard
- A third-party tool
ULS logging levels
There are six possible logging levels available to be reported within the trace log: none, unexpected, monitorable, high, medium, and verbose. Table 1 provides insight into what each level of logging entails.
TABLE 1 ULS logging levels
| Level | Definition |
| None | No trace logs are written to the file system. |
| Unexpected | This level is used to log messages about events that cause solutions to stop processing. When set to log at this level, the log includes only events at this level. |
| Monitorable | This level is used to log messages about any unrecoverable events that limit the solution’s functionality but do not stop the application. When set to log at this level, the log also includes critical errors (unexpected level). |
| High | This level is used to log any events that are unexpected but do not stall the processing of a solution. When set to log at this level, the log will include warnings, errors (monitorable level), and critical errors (unexpected level). |
| Medium | When set to this level, the trace log includes everything except verbose messages. This level is used to log all high-level information about operations that were performed. At this level, there is enough detail logged to construct the data flow and sequence of operations. This level of logging can be used by administrators or support professionals to troubleshoot issues. |
| Verbose | When set to log at this level, the log includes messages at all other levels. Almost all actions that are performed are logged when you use this level. Verbose tracing produces many log messages. This level is typically used only for debugging in a development environment. |
As the level of detail in the ULS logs increases (starting with none and working upward in detail toward verbose), each additional level of detail increases the corresponding amount of storage required to house all the log files.
Configuring ULS logs from Central administration
Central Administration provides an easy-to-use interface for the configuration of event and
ULS logs.
To configure the monitoring level, do the following:
1. Open Central Administration and select Monitoring.
2. In the Reporting section, select the Configure Diagnostic Logging link.
3. The Diagnostic Logging page appears. Within the Category section, you see three tiers of selections (see Figure 1). From here, you can make choices as follows:
A. All Categories The changes you make apply universally to every service
B. Individual Services The changes you make apply to the entire service (such as Access Services)
C. Category The changes you make apply only to a subcomponent of the individual service
FIGURE 1 Diagnostic logging levels
4. After you select the services you are interested in logging at a certain level, you can choose the least critical event you want to report for both the event level and trace level (ULS):
A. Least Critical Event To Report To The Event Log (reset to default, none, critical, error, warning, information, verbose)
B. Least Critical Event To Report To The Trace Log (reset to default, none, unexpected, monitorable, high, medium, verbose)
VERBOSE LOGS AND STORAGE
A word of caution here. Setting verbose for the event log or trace log can quickly generate large amounts of logging data, potentially filling your available drive space. This can be further amplified by selecting options such as All Categories, which enables this level of granularity for each and every category. If you have made changes to the logging settings and can’t remember what exactly was done, you can always reset both the event log and trace log to the reset to default selection. It does not clear the log space, but does stop the addition of more log data.
5. Event Log Flood Protection enables the system to avoid the endless repetition of a particular event in the Windows event log. It is always a good idea to leave this value enabled.
6. The Trace Log section enables you to “catch” the system before it can completely fill a drive.
A. Path The trace log path is usually set to the default path, “%CommonProgramFiles%\Microsoft Shared\Web Server Extensions\15\LOGS\”, which also happens to be the system drive. If you are expecting a large volume of log data, even temporarily, consider moving the trace log until things return to normal.
B. Number Of Days To Store Log Files This value defaults to two weeks (or 14 days). If you have an extended event that requires further analysis, you can change the duration for which a trace log is retained.
C. Restrict Trace Log Disk Space Usage This check box enables you to specify a maximum amount for trace log retention. This setting is particularly useful in smaller environments with restricted amounts of drive space.
7. Click OK when you finish making configuration changes to the diagnostic logs.
analyzing the trace log with ULSViewer
SharePoint assigns a correlation log ID to every series of SharePoint actions taken on a particular farm member. These values take the form of a GUID and signify a “conversation” of sorts, grouping together a sequence of actions.
There are several ways to analyze the trace logs on a server:
- Use Notepad or another text editor. You can open a trace log in Notepad and search for a correlation ID, but an entry for a particular sequence of events may be several lines long.
- Use Windows PowerShell. The Get-SPLogEvent cmdlet enables you to parse through a trace log to find correlation IDs.
- Use a third-party application. This example uses the ULSViewer application. This application is available from MSDN at http://archive.msdn.microsoft.com/ULSViewer/Rehttp://archive.msdn.microsoft.com/ULSViewer/Release/ProjectReleases.aspxlease/ProjectReleases.aspx.
Regardless of how you choose to analyze the ULS logs/trace logs, knowing their function and being able to configure and evaluate them are key SharePoint skills.
Figure 2 indicates a particular issue when rendering a welcome page on a publishing site. This error appears every time a page load is attempted.
FIGURE 2 Failed page load
To troubleshoot this issue, you can open the trace logs on the affected SharePoint Server.
TRACE LOGS ARE SERVER-SPECIFIC
Each SharePoint server has its own copy of these trace logs. In a farm that has multiple web servers, you may need to analyze the trace logs on each server in order to locate an issue.
ULSViewer does not require any sort of installation mechanism; you merely download it and run it directly. Selecting and running ULSViewer.exe causes the ULS viewer to appear in a window (see Figure 3).
FIGURE 3 Opening the current trace log.
At this point, trace log messages begin to fill the ULS RealTime tab. You need to re-create the error, so let’s attempt to load the errant page again (see Figure 4).
FIGURE 4 Page load still failing.
Selecting the Technical Details link shows the correlation ID GUID associated with this problem (see Figure 5). Select the first section of the GUID, right-click, and select Copy.
FIGURE 5 Copy correlation ID GUID
Although you can copy the entire GUID, it is not necessary because the first section should be enough to locate the error within the trace log.
Switching back to ULSViewer, select the Filter icon (see Figure 6).
FIGURE 6 Selecting the Filter icon.
Select the following values and then click OK (see Figure 7):
- Field, Correlation
- Operation, Contains
- Value, <partial GUID copied earlier>
FIGURE 7 Filtering by correlation value.
When the grouping of correlation messages appears (see Figure 8), you can see the sequence of events both before and after the issue. In this case, the system has thrown an exception because the seattle.master page has a simple typo in it (compare the Unexpected error with the original error message shown when the page was loaded).
FIGURE 8 Unexpected error in ULS viewer
Discarding the erroneous master page and reverting to the previous version corrected the issue (see Figure 9).
FIGURE 9 Corrected publishing page.
