Category Archives: Uncategorized

Debugging SharePoint Issues and ULS Log Files

I often see administrators and developers new to SharePoint find debugging difficult and complex.

When working with SharePoint, log files are your friend.  In large on-premise farms, locating issues within large log files can be time consuming and sometimes difficult.

When I am presented with an error that contains a correlation ID, I first resort to PowerShell instead of a ULS Viewer.

Two PowerShell cmdlets that are your friend are: Get-SPLogEvent and Merge-SPLogFile.

Before you can use these cmdlets in your PowerShell scripts, make sure to load the SharePoint PowerShell snapin.

if((Get-PSSnapin -Name Microsoft.SharePoint.PowerShell -ErrorAction SilentlyContinue) -eq $null)
    Add-PSSnapin Microsoft.SharePoint.PowerShell -ErrorAction SilentlyContinue


The Get-SPLogEvent cmdlet will retrieve specific events from a ULS Log File.  For example, the following call will retrieve all entries that occurred during a specified time range:

Get-SPLogEvent -StartTime "12/04/2007 17:00" -EndTime "12/04/2007 18:00"

If you wish to retrieve ULS entries associated with a specific correlation ID, you can use the following:

Get-SPLogEvent | ? {$_.Correlation -eq "<Correlation ID>"} | Select Area, Category, Level, EventID, Message

Where <Correlation ID> is the id you wish to filter.

If you wish to display the results in a nicely formatted list, add Format-List:

Get-SPLogEvent | ? {$_.Correlation -eq "<Correlation ID>"} | Select Area, Category, Level, EventID, Message | Format-List

Be patient when running the Get-SPLogEvent cmdlet as it can take quite a long time to traverse through all the ULS log files.

I have a diagnostics PowerShell library that contains many functions that simplify diagnosing issues, writing log files, etc.  One of the functions in this library is my Get-SPLogEventByCorrelationID.  Which simply calls the Get-SPLogEvent cmdlet and filters the results by a specified correlation ID.

function Get-SPLogEventByCorrelationID
    $logEntries = Get-SPLogEvent | ? {$_.Correlation -eq $CorrelationID} | Select Area, Category, Level, EventID, Message

For more information on using the Get-SPLogEvent cmdlet, see the following:


The Merge-SPLogFile cmdlet combines ULS log entries, from all servers in a SharePoint farm, to a single (specified) log file.

The following example will merge all ULS log files for the last hour:

Merge-SPLogFile -Path "C:\Logs\FarmMergedLog.log" -Overwrite

If you wish to merge all ULS log events for a specific correlation ID, you can use the following call:

Merge-SPLogFile -Path "C:\Logs\FarmMergedLog.log" -Correlation "<Correlation ID>" -Overwrite

Where <Correlation ID> is the id you wish to filter.

As with the Get-SPLogFile, I have included some common functions in my diagnostics library.  One that I use on a regular basis is Merge-SPLogFileByCorrelationID

function Merge-SPLogFileByCorrelationID

    $ls = "".PadRight($LeadingSpaceCount," ")
    $diagConfig = Get-SPDiagnosticConfig
    $ulsLogLocation = $diagConfig.LogLocation + "\MergeLog-Correlation (" + $CorrelationID + ").log"
    Write-Verbose ([string]::Format("$ls- Writing merged logs to file [{0}].", $ulsLogLocation))
        Merge-SPLogFile -Path $ulsLogLocation -Correlation $CorrelationID -Overwrite
        Merge-SPLogFile -Path $ulsLogLocation -Correlation $CorrelationID

Other References


With a little knowledge and tools, you can become efficient at debugging issues in SharePoint.  If you would like a copy of my diagnostic script, please contact me; I will be happy to send it to you.

Happy SharePointing!

10 Key Elements of Enterprise Information Architecture (#IA) – #1 Content Categorization

This article is the first in a series of ten that will help you better understand the 10 key elements of Enterprise Information Architecture (#IA).

Information Architecture consists of many techniques and principals that are required to ultimately add value to day-to-day business operations. When we look at everything involved with Information Architecture, it can be overwhelming and complex. For these reasons, I have broken down Information Architecture in to the following 10 Key Elements. These are by no means all inclusive but what can be considered the most important.

  1. Content Categorization (this article)
    Content Categorization – Common Categorization and Grouping Mistake
  2. Understanding
  3. Presentation
  4. Evolution
  5. Responsibility
  6. Process
  7. Metadata
  8. Search
  9. Security
  10. Governance

Content Categorization

In this first article, we will focus on Content Categorization.  It is the first of the 10 Key Elements of Enterprise Information Architecture and , surprisingly, the one that is most often overlooked.

If you currently have SharePoint installed in your environment and are encountering issues, such as little organization, users unable to find their content, low adoption rate, etc., then you have most likely implemented your solution with little to no Information Architecture.

Content Categorization and classification is the process by which we identify and group content.  One key success factor for all SharePoint implementations is to reduce, if not eliminate, the question “where do I store and manage my content”.  Content Categorization and classification aids with this by providing a specific location and manner by which users store and manage their content.

Content Categorization and classification is one of the primary ways we query content for improved search relevancy and aggregation.

Content Classification
Content Classification consists of labeling types of content using labels that precisely describe what the content is. For example instead of all documents being labeled as merely a Document type, we classify our documents with more precise labels; such as Policy Document, Client Contract Document, Vendor Contract Document, Project Plan Document, Medical Benefit Document, etc.

Content Classification in SharePoint is accomplished by using content types. A content type defines a single data type, such as Policy Document, and supports associating metadata, a template document, workflow and policies.

05.03.01 - Policy Document Content Type

Once your content has been classified, it becomes a relatively simple process to create search scopes (result sources) and points of aggregation. For example, it is quite easy to create a result source containing all documents of type Policy Document. We can then search all documents of type Policy Document and/or aggregate all Policy Documents to a policy book.

Content Grouping
Grouping consists of grouping content of similar type. For example a document library, in SharePoint, named Documents really doesn’t have much meaning and certainly doesn’t tell a user what is stored in it. However, a document library named Policy Documents or Benefit Documents clearly defines what is contained within.

05.03.01 - Policy Documents Library

Another example would be a Meeting Documents library, on a project site. The Meeting Documents library might contain meeting agenda, meeting minutes and meeting action items documents. In this example, the Meeting Documents is the document grouping principal and is a container for managing all documents related to project meetings.

Content Grouping isn’t limited to lists and libraries. Each container level in SharePoint can be used to apply grouping principals. Each of the following is a grouping container in SharePoint.

  • SharePoint Farm – The top-most grouping level in SharePoint.       A corporate solution will have 1 to many SharePoint farms.
    • Web Application – Each SharePoint farm will include 1 to many web applications.
      • Site Collection – Each web application will contain 1 to many site collections.
        • Top-level Site – Each site collection will have a single top-level site.
          • List – Each top-level site can have 0 to many lists.
          • Document Library – Each top-level site can have 0 to many document libraries.
            • Folder – Each library can have 0 to many folders. (See Note Below)
          • Sub-sites – Each top-level site can have 0 to many sub-sites.
            • List – Each sub-site will have 0 to many lists.
            • Document Library – Each sub-site can have 0 to many document libraries.
              • Folder – Each library can have 0 to many folders. (See Note Below)


As you can see there are many grouping levels that can be applied to your SharePoint implementation. Each of these grouping levels has a very specific purpose and is used for many different reasons.

The goal is to reduce the use of folders and expand them to document libraries instead. It is also very common to group similar information, by topic, by site. For example, you may wish to have a sub-site, below the top-level site for each department, titled Policies & Procedures. This site would contain many lists and libraries all related to human resources policies & procedures; i.e. policy documents, procedure documents, FAQ’s, glossary terms, etc.

Note About Library Folders

The regular use of folders in libraries is not considered a best practice. There are very specific cases when folders do make sense and are used; however, these cases are limited.

SharePoint 2013 Intranet Management, Design and Architecture Training

These ten elements are defined, in detail, in my SharePoint 2013 Management, Design and Architecture Training Course.  For those of you who recall my Information Architecture course for SharePoint 2010, this new course expands on all the new features of both on-premise and Office 365 environments.

If you are interested in learning more about how to implement a SharePoint 2013 Intranet solution, please register for our next class.