Summary: Guest blogger Microsoft PFE Chris Weaver talks about the greatest SharePoint 2010 Windows PowerShell cmdlet.

Microsoft Scripting Guy, Ed Wilson, is here. This weekend is going to be a guest blogger weekend. Today we have back with us Microsoft PFE Chris Weaver. Read more about Chris and his previous guest blog posts here. Take it away, Chris …

I was trying to think of the greatest cmdlet I have used within the SharePoint 2010 arsenal, and the first thing that came to mind was Merge-SPLogFile. Now, this might just be because of working in support, but I find this cmdlet saves me and my customer at least an hour of work every time ULS logs are required to help troubleshoot an issue—just think if you have seven or more SharePoint servers in your farm and you need to go manually collect all the log files for a particular time, copy them over the network, etc.

For those of you who are new to SharePoint, or don’t really use it often, the ULS logs are files located locally on each server and almost everything that happens in SharePoint could get logged there depending on the Verbosity set in diagnostic logging. To further understand the diagnostic logging settings, see this blog.

This great little command can do some very heavy lifting—it will gather the ULS logs from each server in your farm and compile it into one file for you, or you can save it to an object and manipulate that object as you wish. But you don’t have to believe me—let’s just play with it a bit.

So, let’s open up the SharePoint 2010 Management Shell (Windows PowerShell that comes with SharePoint and has the PSSnapin already loaded through the profile), and I recommend right-clicking it, and then selecting Run as Administrator. Type the follow command:

 Get-Help Merge-SPLogFile

As you can see, there are several different parameters we can use when we want to run this command, the first command to look at is using only the parameter -Path.

 Merge-SPLogFile -Path C:\Logs\Uls.log

This command will go to every SharePoint server in your farm, and by using a timer job will gather one hour of ULS events, and then write them to the text file defined by the -Path parameter.  This honestly is the most common way that I use this command. I will have my customer reproduce the issue, and then run the command to gather ULS logs from all servers.

The second most common combination of parameters for the command is using two different parameters: -StartTime and -EndTime.

Merge-SPLogFile -Path C:\Logs\Uls.log -StartTime “10/26/2012 01:00” -EndTime “10/26/2012 05:00”

This command gathers the ULS logs from all the SharePoint servers between the Start Time and End Time. These times are represented by MM/DD/YYYY for the date, and HH:MM on a 24-hour clock for the time. These times are also culture-specific to the version of the operating system.

The last combination I like to use is using a new feature in the ULS logs and that’s called the correlation ID, which is represented by the parameter -Correlation.

Merge-SPLogFile -Path C:\Logs\Uls.log -Correlation e6f433ae-4a18-4a68-8874-bb2e1bfac95e

This command gathers all events in the last hour with the Correlation ID e6f433ae-4a18-4a68-8874-bb2e1bfac95e for the last hour. Just in case you were wondering, the Correlation ID is a GUID that is attached to all requests for the SharePoint servers. This way you can trace an error to its originating request.

Just to revisit: Merge-SPLogFile has several parameters that I have given a few examples of, and, if you wanted to, you could use all of those parameters together to gather events from all SharePoint servers from some Start Time to and End Time with a specific Correlation ID and have it written to a single file.

If you ask me, this cmdlet rocks.

Thank you, Chris, for sharing your time and knowledge. Join me tomorrow when Chris Wu shares his knowledge.

I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.

Ed Wilson, Microsoft Scripting Guy