Thursday, 15 October 2009

Administration: Find the needle in your (MOSS) event log haystack

Those that follow my blog may be expecting this post to be part 2 of my corporate security review series (part one is here). However, I figured I would save that post for next week and instead share something that I use on a regular basis whilst looking after our MOSS farm. I hope it's of use to you.

As a MOSS Server farm administrator, we get used to seeing a fair few common event IDs in Windows server event logs. Most of them are simply "informational" messages, but it's also common to see numerous warnings and errors. The challenge is knowing which events are a threat to your SharePoint installation and which ones are safe to ignore. As diligent server administrators we strive to remove each and every warning from the event log but in reality this can be a very difficult task in all but the smallest of farms.

To record common events, I keep a log handy (no prizes for guessing that it takes the form of an Excel spreadsheet stored within a SharePoint document library). I have included the most common issues contained in this list below. Note that although I have compiled this list based on my own experiences and research (read "googling"), I can't guarantee that the resolution will work for you as every SharePoint installation is different.

Please take a look and let me know if any of these look familiar:

Common MOSS related Windows Event IDs:
  • 6398, 7076 and 6482 (Errors): "Unhandled Exception: System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt."
  • Hay: No direct issues to my knowledge but 3 errors at once is an eyesore in your Windows event log. Apply the hotfix.
These three errors tends to show up together every hour or so and can certainly look rather worrying in the Windows event log. In my experience I haven't noticed a problem that has occurred directly as a result of this issue (supposedly a compatibility issue between a .NET 2.0 remoting application and Windows Server 2003 SP2), but I would certainly recommend downloading and installing the MS hotfix contained in the link below.

Temporary resolution: restart restart the "Windows SharePoint Services Administration" & "Windows SharePoint Services Timer" services.
  • 6875 (Error): "Error loading and running event receiver
    Microsoft.SharePoint.Publishing.Internal.ScheduledItemEventReceiver in
    Microsoft.SharePoint.Publishing"
  • Hay: An informational error message (thanks Microsoft) - safe to ignore until you deploy MOSS SP2 which includes the hotfix.
This used to appear for us whenever we published a page in SharePoint when major versioning was turned on (which I believe is turned on by default within a publishing portal). As you might expect, the error cropped up a lot. The good news is that it is safe to ignore as the message is, according to MS an "informational" error. The best news? The hotfix is contained with MOSS SP2 so the error should disappear once you get around to deploying the service pack.

  • 7078 (Warning): "Job 'User Profile Incremental Import Job' failed. It will be re-tried again in 240 second(s). "
  • Hay: Due to SharePoint starting multiple jobs at once - check your timer job definitions in Central Administration for conflicts but otherwise safe to ignore.
This one occurs for us approximately once per week at varying times and in my opinion is safe to ignore (after all, the warning does state that the job will rerun). There doesn't appear to be a documented resolution from Microsoft thus far.

  • 2436 (Warning): "The start address cannot be crawled "
  • Needle:Typically due to incorrectly defined start addresses - check Central Administration.
For us, this was simply a case of human error and was very straightforward to correct within Central Administration > > Content Sources > Edit Content Source. In our case, we ensured that our start addresses matched the default URL's defined within "Alternate Access Mappings".
  • 1113 (Error): "One of the IP/Port combinations for site 'ID' has already be configured to be used by another site. The other site's SSL configuration will be used. "
  • Hay, so long as your IIS sites are up and running: A bug introduced by a new feature in Windows Server 2003 - safe to ignore.
If you host multiple Web sites on the same IP address and use host headers to differentiate your sites in IIS 6.0 (common for SharePoint installations), you may find (if using Windows Server 2003) that this error appears in your log whenever you perform an IIS reset. From what I gather, this is because prior to SP1, server 2003 could not handle host headers over SSL as host headers are encrypted and IIS had a hard job knowing which site to redirect the encrypted request to (a good example of the "chicken and egg" problem). Thankfully, the smart people over at Microsoft provided support for "wildcard" SSL certificates in SP1 but forgot to remove the error message above. I do not know of a way of removing the error but I am confident that this should not be a problem for you so long as your IIS is configured correctly.

Note that in cases where your IIS 6.0 installation is not configured correctly, you will certainly know about it if the problem is related to SSL bindings as your Web sites will effectively become unavailable, especially if publishing SharePoint via a secure proxy such as ISA Server 2006.

  • 1310 (Warning): "A configuration error has occured: duplicate "System.Web.extension" tags"
  • Needle: Remove the duplicate web.config tags.
This used to occur for us a regular basis whilst deploying SharePoint Web applications. I never quite put my finger one what caused this problem but the fix was as simple as removing the offending duplicate tags from the applications web.config file. In the case above, SharePoint duplicated the "System.Web.Extensions" tags rendering the site inaccessible.

That concludes today's post. Let me know if you find any "needles" in your MOSS event log haystack that I haven't covered.

Subscribe to the RSS feed

Follow me on Twitter

Follow my Networked Blog on
Facebook

Add this blog to your
Technorati Favourites

1 comment:

  1. I am sure this would help people in getting to the root of a number of issues related to SharePoint.

    ReplyDelete