Monitoring SharePoint 2010 WHAT’S IN THIS CHAPTER? Improvements in diagnostic log management Using correlation IDs Using the logging database If you’ve made it this far you’ve got SharePoint 2010 installed and running. You’ve created a web application or two and uploaded some content. You’ve probably confi gured some service applica- tions and sent them off to do their work. SharePoint is doing its thing and life is good. You might be tempted to lean back in your chair and put your feet up, but your adventure is not fi nished. While SharePoint might be spinning like a top now, the day will come when there are problems. When that happens, you will need to know how to fi nd out what’s troubling SharePoint so that you can fi x it. A lot of work has been put into monitoring in SharePoint 2010. So much has been added that Monitoring has been given its own tab in Central Administration. SharePoint will report errors, but you need to know where to fi nd them. This chapter will show you how to keep an eye on SharePoint, both in proactive and reactive ways so that you can keep your SharePoint servers in tip-top shape. This will enable you to fi x SharePoint when it’s broken, as well as see where problem areas are before they become bad enough that your end users com- plain. Nobody likes that. UNIFIED LOGGING SERVICE We will start our journey toward SharePoint monitoring enlightenment with the Unifi ed Logging Service (ULS). To the seasoned SharePoint administrator, the ULS logs are nothing new. They have been around for a version or two of SharePoint. SharePoint 2010 carries on that tradition but improves on it. The ULS surfaces information in three different places; trace logs, Windows Event Viewer, and a new reporting database. This chapter covers all three areas and explains how they differ. 15 412 CHAPTER 15 moNitoriNg sharePoiNt 2010 ULS is sort of like SharePoint’s tattletale. It is only a logging service; it does not act on any of the events that it sees. However, as you’ll see later in this chapter, SharePoint monitoring is more than just the ULS logs and is not always passive. The ULS service’s purpose in life is to provide the SharePoint administrators or operations teams with all the information they need to solve problems, or head prob- lems off at the pass. The hope is that with all the information that ULS provides, you should be able to spend fewer resources keeping an eye on SharePoint; and in the unlikely event of a SharePoint prob- lem, the ULS should provide you with the information you need to resolve the problem quickly. Trace Logs When most SharePoint administrators hear “ULS” they immediately think of the ULS logs that they have been using for years with previous versions of SharePoint. In SharePoint 2010 these are offi- cially referred to as the trace logs. The trace logs have a similar address to their counterparts in pre- vious versions of SharePoint. You can find them in the Logs folder of C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\ . That’s quite a mouthful, so Microsoft has lovingly christened that path the “SharePoint Root.” You may also hear some less refined people refer to it as the “14 Hive.” Figure 15-1 shows what you can expect to see if you look for the ULS trace logs in Explorer. The filename consists of the server name, the date in four-digit year, month, and date order, followed by the time in 24-hour format. You’ll also notice that the duration between log file creation is always exactly 30 minutes apart, at least while the machine is on. This is the default setting, although you can use Windows PowerShell to change this. See the sidebar for more information on using PowerShell with trace logs. FIGURE 151 Unified Logging Service 413 If you open one of the trace logs, you will see that it is packed full of great SharePoint information, probably more than you need on a daily basis. The good news is that you will probably access the trace logs only when you’re researching a problem. The bad news is that even then, there still might be more information presented than what is really helpful for troubleshooting your issues. You’ll see later how to control how much information is added to the trace logs. Improvements from SharePoint 2007 If you used SharePoint 2007 at all you’re probably asking yourself what’s so special about trace logs in SharePoint 2010. We’re glad you asked. While they are similar in intent, the trace logs received a number of really exciting improvements. Figure 15-1 hinted at the first improvement; the log files are smaller. A lot of changes have made that possible. From Figure 15-1 you can see that by default the log files themselves are compressed on the drive, using NTFS compression. Because the logs are text files and consist of a lot of repeating data, they compress very well. The files in Figure 15-1 each show a size of around 31MB, but each actually uses around 13MB on disk due to the compression. That’s over 50% smaller and the only penalty is some CPU cycles. To make the files even smaller, many of the noisy events that were written to the SharePoint 2007 log have been removed. To better manage the information written to the trace logs, the throttling interface has been given a complete overhaul. In SharePoint 2007, the information written to the trace logs could be controlled, to a point. Unfortunately, it wasn’t very useful. If the diagnostic levels were increased to troubleshoot a problem, it was impossible to determine which settings had been changed. Moreover, even if you knew which levels had been changed, there was no way to determine what they had been changed from. It was a mess. In SharePoint 2010 this has all been fixed. To get to the new Event Throttling settings, go into Central Administration and click Monitoring on the left navigation pane. Figure 15-2 shows all the Monitoring links. FIGURE 152 414 CHAPTER 15 moNitoriNg sharePoiNt 2010 In the Reporting section, click “Configure diagnostic logging” to get to the Event Throttling set- tings, shown in Figure 15-3. Compared to SharePoint 2007, you’ll notice a wider variety of catego- ries. This makes it easier to determine which category covers the event you want to find. Expand the category to see the settings each contains. This demonstrates two improvements over SharePoint 2007. First, you have more granular ability to find the settings you’re looking for. One of the diag- nostic categories in SharePoint 2007 was General/Administration, which isn’t particularly helpful when you’re trying to find where you can increase logging. Second, the interface has checkboxes so you can alter multiple events at once. FIGURE 153 Some features are shared with SharePoint 2007. For example, you can control how much informa- tion is written to the trace logs as well as the Windows Event Viewer. You can choose from among several logging levels. For the Windows Event Log, the events are listed in order of fewest messages to most: None, Critical, Error, Warning, Information, and Verbose. For the trace logs you can select None, Unexpected, Monitorable, High, Medium, or Verbose. You can easily change both settings for multiple events on one screen. As you can see, altering the diagnostic levels is much easier in SharePoint 2010. Easy alterations can be a good feature, but it can also be bad. It enables you to fine-tune the changes you need, but it can also mean changing many settings back once you’ve successfully fixed the issue you’re investigating. Fortunately, SharePoint 2010 provides improvements in that area as well. Any time you change a diagnostic level, that category appears in bold in the interface (refer to Figure 15-3). Unified Logging Service 415 It’s one thing to know which settings have been changed; it’s another to know what to reset them to. Have no fear; SharePoint 2010 takes care of that too. One of the event levels to which you can set a category is Reset to default, as shown in Figure 15-4. FIGURE 154 The combination of those two improvements makes it easy to get your diagnostic levels back to their defaults after you’ve cranked them up to investigate an issue. Trace Log Settings A few other settings are related to the trace logs. They involve the location of the trace logs and how long to keep them. As noted earlier, by default they are written to the Logs directory of the SharePoint Root. You can, and probably should, move them to a different location. That’s because in most cases Windows is installed on the C: drive, and the SharePoint Root must be on the C: drive. Therefore, it’s a good idea to leave the C: drive with as much free space as possible. Moving the trace logs to a different drive reduces the possibility of filling up the C: drive. Figure 15-5 shows SharePoint writing the trace logs to D:\SharePoint\Logs. Keep in mind that this is a farm-level setting, it is not per server. Any path you put here must exist on all servers in the farm. If you try to enter a path that does not exist, SharePoint will not let you save it. This is also a concern when you add new servers to your farm; make sure they also have the trace log path available. 416 CHAPTER 15 moNitoriNg sharePoiNt 2010 FIGURE 155 Figure 15-5 shows the other trace log settings that are available to you. They are used to restrict the storage space used for trace logs. You have two methods to control their growth. One option is to control how many days’ worth to keep. The default value is 14 days; with this value, on day 15 the logs from the first day are deleted. The other option is to absolutely restrict the amount of drive space available to the trace logs. The default, and maximum, value is 1000GB. If you choose to restrict drive space, then both settings are used to control the logs. If the logs are small and don’t hit the space restriction, then they will be pruned based on the day restriction. If the logs are very active and they reach the space restriction before the day restriction, they will be pruned. Trace Logs Administration with Windows PowerShell Windows PowerShell can be used for many amazing tasks. The following sections demonstrate the PowerShell cmdlets useful for working with trace logs. Configuring Diagnostic Log Settings with Windows PowerShell If you’re the scripting type, you can use Windows PowerShell to view and configure SharePoint’s diag- nostic log settings. You can use the cmdlet Get-SPDiagnosticConfig to get a list of the farm configu- ration settings. If you want to change any of the settings, use the cmdlet Set-SPDiagnosticConfig to assign the values you want. The following command will change the number of days SharePoint keeps the trace logs to 30 days: Set-SPDiagnosticConfig -DaysToKeepLogs 30 Unified Logging Service 417 Changing Logs with Windows PowerShell You also have the option to use Windows PowerShell to set and get the logging level for specific cat- egories. Running the cmdlet Get-SPLogLevel with no parameters will report the logging level for all categories. If you want to change a category’s level, use Set-SPLogLevel to alter the category’s value. PowerShell can also manipulate the trace files themselves. New-SPLogFile tells SharePoint to create a new trace file. This is a great diagnostic technique. If you create a new trace file before you start troubleshooting, you will know exactly which file contains the error. To take it another step, use Merge-SPLogFile to merge all the trace files in your farm into a single file on the local computer. To get the entire list of trace file–related cmdlets, use the following command: Get-command –noun splog* Correlation IDs There is one addition to the trace logs that does help you hone in on the information you need. SharePoint 2010 introduces correlation IDs. Correlation IDs are unique GUIDs that are assigned to each user conversation with SharePoint. They are like breadcrumbs that a SharePoint administrator can use to follow a user around and see what they were doing if there is a problem. Nothing is more frustrating when troubleshooting than when you ask a user, “What were you doing when you got the error?” and they reply, “Nothing.” Correlation IDs are like flashlights guiding us through the fog of unhelpful users. Correlation IDs will surface when SharePoint crashes in the browser. The user will still get the ever helpful “An Unexpected Error Has Occurred” message or something else equally helpful. On top of that, though, they will get a correlation ID in the form of a Globally Unique IDentifier, or GUID to its friends. GUIDs are randomly generated and in the form of “601487bc-1a65-4d4a-70dd- bf9c01e57e8b.” There will a correlation ID in this form on the error page, like you see in Figure 15-6. As a SharePoint administrator, you can take this correlation ID and search through your trace logs to follow the user’s conversation with SharePoint, as well as see exactly which lines in the trace logs deal with that failure. Figure 15-7 shows some of the corresponding trace log entries to the error shown in Figure 15-6. No more searching through trace logs trying to figure out which lines pertained to which errors. Now it is all mapped out for you, with a lighted path. FIGURE 156 418 CHAPTER 15 moNitoriNg sharePoiNt 2010 FIGURE 157 To make your troubleshooting even easier, correlations IDs are persisted across servers in your farm. So if a user initially hits SERVER1, which is running the web front end role, and that renders an Excel spreadsheet that is calculated on SERVER2, the correlation ID for the conversation will be the same on SERVER1 and SERVER2. The correlation ID is even available as a filter if you are doing SQL tracing on your SQL server. You can use the Windows PowerShell cmdlet Merge-SPLogFile to merge the trace logs from all the servers in your farm into a single file. This allows you to do one search for the correlation ID and get the activity from your whole farm. Since a correlation ID is generated for every conversation, there doesn’t need to be an error in order for you to follow the conversation. You might use it to see why a particular web page is loading slowly, or why a certain Web Part doesn’t load correctly. To get the correlation ID without an error page you can enable the developer dashboard, as it reports the correlation ID. What’s the developer dashboard, you ask? This is what storytellers call “foreshadowing.” Read on to learn about the developer dashboard. Unified Logging Service 419 Developer Dashboard While this book is squarely aimed at SharePoint administrators, we need to cover a new piece of functionality called the developer dashboard. Despite what the name may suggest, it’s not just for developers. The developer dashboard is dashboard that shows how long it took for a page to load, and which components loaded with it. A picture is worth 1000 words, so Figure 15-8 probably explains it better. FIGURE 158 This dashboard is loaded at the bottom of your requested web page. As you can see, the dash- board is chock full of information about the page load. You can see how long the page took to load (708.77 ms) as well as who requested it, its correlation ID, and so on. This info is useful when the helpdesk gets those ever popular “SharePoint’s slow” calls from users. Now you can quantify exactly what “slow” means as well as see what led up to the page load being slow. If Web Parts were poorly designed and did a lot of database queries, you’d see it here. If they fetched large amounts of SharePoint content, you’d see it here. If you’re really curious you can click the link on the bottom . versions of SharePoint. In SharePoint 2010 these are offi- cially referred to as the trace logs. The trace logs have a similar address to their counterparts in pre- vious versions of SharePoint. . moNitoriNg sharePoiNt 2010 ULS is sort of like SharePoint s tattletale. It is only a logging service; it does not act on any of the events that it sees. However, as you’ll see later in this chapter, SharePoint. Monitoring SharePoint 2010 WHAT’S IN THIS CHAPTER? Improvements in diagnostic log management Using correlation IDs Using the logging database If you’ve made it this far you’ve got SharePoint 2010