MOSS@MS

Returning search results as XML

When troubleshooting search problems you may want to be able to see search results without the XSLT transformation.  In other words in XML without the formatting.  This can be useful when troubleshooting search results because it enables you see the raw XML data so you can see all of the fields. 

By default you see search results as follows :

To see the underlying XML follow the steps below.

1. Click on Site Actions, Edit Page.
2. In the Search Core Results we part click edit, Modify Shared Web Part.  Next click the XSL Editor button.
3. Replace the existing XSL with the XSL below (save off the existing XSL if you wish)

   <xsl:stylesheet version="1.0"   xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> <xsl:output method="xml" version="1.0" encoding="UTF-8" indent="yes"/> <xsl:template match="/">   <xmp><xsl:copy-of select="*"/></xmp> </xsl:template> </xsl:stylesheet>

4. Click Save and OK then Exit Edit Mode.
5. Now search again.  You should see something like the results below (I've masked my server name deliberately).  As you can see the formatting has been removed allowing you to see only the XML.

Using the ExportCrawlLog STSADM Extension

This is a very useful tool that is available on codeplex - http://www.codeplex.com/ExportCrawlLog 

It aims to give administrators the ability to export the Crawl log (formerly known as the Gatherer log) and is installed as a stsadm extension.  Although you can see the crawl log in SSP Administration by going to Search Administration, Crawl log, there is no simple way of exporting it.  This extension will give you the ability to export the crawl log and manipulate the output by host and/or date and time.

How do I install it?

Download the .zip archive form the location above and extract it.  Run the deploySTSADMExportCrawlLog.cmd command.  This may fail and report problems "adding assembly to the cache".  If this is the case first use explorer to open up C:\WINDOWS\assembly.  Next go to the ..\bin\Release folder and drag and drop the STSADMExportCrawlLog.dll into C:\WINDOWS\assembly.  Check that under the ..\Common Files\Microsoft Shared\web server extensions\12\CONFIG folder there is a stsadmcommands.STSADMExportCrawlLog.xml file present.

How do I use it?

Start a command prompt and path to the BIN folder.  You will now be able to use the extension in the following way :

stsadm -o ExportCrawlLog
-t (d|s|c|p) -site <portal url> [-outfile filename] [-history] [-s startdatetime] [-e enddatetime] [-from #] [-thru #] [-cat (Portal_Content|ProfileImport)] [-csid #] [-msgid #] [-u url pattern] [-hostname hostname] [-mt (s|w|e)]
where -t = type: d=details, s=summary, c=content sources and start addresses
where -mt = Message type to include in output (applies to -t d only, if -mt is used only one message type can be specified, when -mt is omitted all types are emitted): s=success, w=warnings, e=errors
where -csid = the # of the content source, which you can spy in the query string of the url of the Content Source edit page.

Here's an example :

You can see the end of the export above.   The command I used is also shown, this gave me a detailed export of a crawl I did on a site on www.microsoft.com (the warnings are expected).  Obviously you can use the -outfile switch to save the log for further analysis.

The Enterprise Search Team have an article describing the extension in more detail, see it at http://blogs.msdn.com/enterprisesearch/archive/2008/05/26/introducing-the-exportcrawllog-stsadm-command-extension.aspx

Getting more value from your error in SharePoint

Error messages are a means of trying to understand why we hit a problem.  Some are helpful while others are not.  Something like "An error occurred" is not meaningful enough to help us drill deeper into an issue to assist in identifying the root cause.

There are steps that we can to give us a more "verbose" set of error messages.  This will take effect on OOB built-in functionality as well as any custom components you have installed.

Consider this example.  When we upload a document into MOSS we hit a problem (I've masked the filename on purpose) :

Obviously this isn't all that helpful.  We could do with some more detail.  Thankfully this is possible by changing a few settings in the web.config for your web application.  You will need to change the value of CallStack and customErrors to true and Off respectively.  Note that changing web.config will cause your application pool to recycle so these changes should take effect immediately.

<SharePoint>
    <SafeMode MaxControls="200" CallStack="true" DirectFileDependencies="10" TotalFileDependencies="50" AllowPageLevelTrace="false">
      <PageParserPaths>
      </PageParserPaths>
    </SafeMode>

</httpHandlers>
    <customErrors mode="Off" />
    <httpRuntime maxRequestLength="51200" />
    <authentication mode="Windows" />

With the changes above when I upload the document instead of the error above we get the one below.  Obviously this offers me much more detail and I can use the exception information to help me search for known issues.

MOSS Diagnostic Logging Part 1

There is a rich diagnostic logging facility in MOSS which can provide us with a powerful set of data in order to drill deeper into problems or allow us to observe what is happening under the hood.  Diagnostic logging is one of the most important tools we have when it comes to troubleshooting support issues.  In this post I will focus on the trace and event logging configured in Central Administration.

By default logging is enabled and it is configured to capture a base set of categories and events that will cover the majority of MOSS operations and tasks.

We configure diagnostic logging in Central Administration, Operations.  Under Logging and Reporting choose Diagnostic logging.  The sections that I will discuss are Event Throttling and Trace Log.

Event Throttling

This is where you can choose from a set of categories that correspond to MOSS components and features.  If you select the drop down list you will see a full list of all categories (there are about 80 or so).  You can also choose the event log and trace log severities for each of your chosen categories.  By default the event level for the majority of categories for the event log is "Error" and the event level for the trace log is "Medium".  Some of the search categories are "Monitorable" rather than "Medium" for the trace log.

You can change the event log and trace log levels for a specific category.  See screen shots below :

Under most circumstances you should leave the logging levels at their defaults.  When looking at a specific issue, you may want to change the trace log level to Verbose and the event log level to Information.  However these changes should be reversed once you are done with analysing your problem.  You can reset logging back to default levels by using stsadm -o setlogginglevel -default

You can also configure logging via stsadm with even greater flexibility, see below :

Trace Log

Under here you can control trace log settings.  The default location is under the 12 hive and we keep 96 logs with each log being used for 30 minutes.  That means we maintain logs for 48 hours.  The settings here are usually sufficient, however you may want to change the number of log files if you are troubleshooting a specific issue over a longer period of time.  If you do this watch disk space usage (see below).

Things to note :

1.  The trace logs can consume a large amount of disk space.  By default we use a .log file for 30 minutes and maintain 96 logs.  How big that log file will become over 30 minutes will depend on server activity and how logging is configured (settings categories to Verbose will create large logs).  You could end up with .log files of several hundred MB.  Multiply that by 96 and you could be consuming several GB's of disk space.

2.  Trace logs are written in English, they are not localised.