With all the advanced integration we have with MOSS you can imagine that some of the most common support issues we deal with somehow involves MOSS. One of the biggest issues out there is figuring out how to debug SharePoint (WSS, MOSS, Forms Server) related issues when all you get is the dreaded "an error has occurred" from Forms Server.  There are a few items in the old tool box which you should be pulling out almost immediately to help yourself out, and we can even add some additional context to assist in your understanding.

Unified Logging System – in SharePoint 2007, all the various teams (WSS, MOSS, Forms Server, BDC, etc) were tasked with using the same API to log to disk.  By default they are found under C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\LOGS and C:\Program Files\Microsoft Office Servers\12.0\Logs.  I usually map a drive to this folder and copy down a few of the most recent files. These files can get quite large so if you have your logging turned way up with too much time in between log files you may have to adjust this,

Use the settings in Central Admin to verify logging is turned on and at an appropriate level.

Central Administration > Operations > Logging and Reporting > Diagnostic Logging – use the settings on this page to throttle up or down logging on your server.

Also check out the following article for some good points at keep log sizes down.

http://blogs.vertigo.com/personal/steventap/Blog/Lists/Posts/Post.aspx?ID=2

Once you get into the logs I am sure you will find that one of the hardest parts of using the logs is parsing them for useful information.  One trick when dealing with the files when you find them is to use Excel 2007 to open them. You can then save it as an XLSX file and do all kinds of fun filtering and the like.

You will be able to filter on category such as Critical, High etc. (very useful when looking for errors, but unfortunately you don't always get the obvious error.)

so you can also filter on the origination of the message such as Search, Excel services, this will be very helpful in searching for problems as you can eliminate all messages that can be unrelated.

This can help to decrease the log down to just a minimum number of messages. So now what do you do with these messages? I am sure you will be surprised if you start to search on them that you will find a significant amount of help out there. You will probably get better and better at spotting the suspicious errors and knowing what to look for. In future blogs we will help to point out some that I have encountered and try to point you to other good resources. Obviously, start with anything that says "error" in the title or description.  From there try to sort out what kind of errors – when dealing with Forms Server, all the errors will typically point to configuration settings that can be changed – "…cross domain support…", "…timeout…", "…external datasource…".  These are all settings on the configurations page in central admin for Forms Server.  You can start by changing those settings, refreshing the page that caused the error and checking the logs again.  NOTE: changes to settings in Central Admin for Forms Server do NOT require an IISRESET.  It is always a bit of trial and error but having useful log data through the trials will help you tremendously.

Another is to use tools that parse the logs, with some kind of community tool. One that I have used with a high level of success is the ULS Log reader available here

http://www.spsdev.com/ulsreader.aspx

SharePoint Logging Spy can be found here: http://www.codeplex.com/sharepointloggingspy.  It makes it easy to get to all the logs and monitor in real time – and it is a standalone exe with no installation – this should make it easier to get into the customer environment.

Scot Hillier has also created LogViewer, a SharePoint feature, and it works quite well.  http://scothillier.spaces.live.com/blog/cns!8F5DEA8AEA9E6FBB!236.entry.  You should take the time to read through this blog entry to see how the logging system works – this will help you understand the logs better.  You should also read through the rest of Scot's blog http://scothillier.spaces.live.com/blog/.  His approaches to development on SharePoint are systematic and sound.  Obtaining his understanding will help you better approach dealing with SharePoint in general.

To deploy Scot's feature, you will need to download the tool and run "STSADM –o addsolution logviewer.wsp" on the SharePoint central admin server and then use the Solution Deployment in the Operations UI (Central Administration > Operations > Solution Management, Logviewer.wsp, Deploy Solution).

SharePoint Object Model – sometimes the only way to see how things are configured in SharePoint is to crawl through files in the \12 directory or entries in the databases.  Not everything is exposed via the UI.  However, nearly every single piece of useful information is wrapped in Object Model (OM) calls.  Now we don't have time to write code to find out what some obscure setting is or to discover some hidden list or site.  For these situations, I use SharePoint Manager 2007 from Keutmann over at SharePoint University: http://www.sharepointblogs.com/keutmann/archive/2007/01/27/sharepoint-manager-2007-update.aspx.  This tool is seriously incredible.  You can see what features are deployed, solutions, settings on any list or site.  You can even do updates to some of the properties.  Download and use it – you won't be sorry. Learning this can also be useful in understanding MOSS in general and also help you other bits of interesting info.

I'm not proposing that these tools are going to tell you what is wrong.  It still takes good diagnostics skills to figure that out.  But hopefully this information and these tools will show you things you haven't seen before and you will be able to start to recognize when something doesn't look right.  It is that understanding that has helped me stumble into the solution to the problem so many times.

This article written by Anthony Petro and Chris Geier