At Microsoft, our support process goes basically like this: Our customers research an issue and don't find any answer using all resources available (Knowledge Base, TechNet, MSDN, www.live.com search, WSS Technical Library, resource kit, etc...) that helps them resolve said issue. They then call in to support, give their name, phone number and other information to a Customer Service Rep, and finally get transferred to a Support Engineer with the incident number. Note: our SharePoint SEs do not operate from a script! They have freedom to troubleshoot an issue in any logical (or illogical) way that they choose. But I digress...
At this point, the customer describes the issue that they are seeing and hopefully then the engineer engages in scoping with the customer. Scoping is the narrowing of focus to single, indivisible issue. An example of where scoping during a call might go like this:
Now we have completely scoped the issue: An executive can't return search results from a document library using a keyword that is known to exist within that document. Specifically the document is a large PDF housed in what appears to be a simple WSS document library.
From the above description, we have a scope, but what should the troubleshooting look like from here? Well, in order to understand this, we need to know a few things:
And we may need to know other things as well:
So how best to gather this data? There are several options. Back in the day (around 10 years ago), our troubleshooting options were pretty limited; screenshots over email or verbal description of each required piece of information. Not too fast these, and our example customer above would be feeling less and less joy with each passing question or email since his CEO is asking for status updates every 23.62 seconds. More recently, remoting technologies like Terminal Services and Microsoft Office LiveMeeting have made the data collection process quicker, but in a case like our example, the level of complexity, and therefore the number of things that may need to be reviewed is huge.
Enter the request for SPSreport from each machine in the farm as made by your friendly Microsoft Support Engineer. SPSreport is a free download from http://www.codeplex.com/spsreport. From the description of the tool on that site:
The SPS Reporting Tool is utilized to gather detailed information regarding a systems current configuration. The data collected will assist the Microsoft Support Professional with fault isolation.
In part two of this web log, I will set up a farm with four SharePoint machines, a remote SQL 2005 server, an Executive team site and a large PDF. I will break the farm so that the symptom, "PDF not showing in search results" happens. I will break the farm in multiple ways, so that reviewing the entire troubleshooting/research process may take more than a single blog to cover completely. By tying the same symptom to various root causes, I hope to show the value of our Support Engineer's request for SPSreports; who knows - maybe by the end of this series our customers will do their research AND run the report for each machine before calling in for support.
See you soon!