in

SharePoint Blogs

The Best Place for SharePoint-related Blogs

share_a_pint

  • A new resolution for Event ID 1000 errors

    Ok...since December 26th, 2007, I've had an open support case with Microsoft Support in regards to some recurring errors that we were seeing in our SharePoint 2003 farm.  Every hour, between 4-6 times depending on which server you look at, each server in the farm would log the error with event ID 1000: #50070: Unable to connect to the database <configuration database name> on <Sql server name>.  Check the database connection information and make sure that the database server is running.

     Well, as you can imagine, we checked the connection, and it was fine.  We also checked everything else under the sun. Probably two or three times.  We recreated the configuration database, and the errors quickly returned. We brought in people from the SQL team, and ran some extensive logging of all of the activity that was occuring, and couldn't find anything.  We tried numerous hotfixes, and removed others that might have caused this as a side effect.

    Finally, after 6 months, and numerous support engineers, I made the discovery by reviewing process monitor logs, that System Center Operations Manager was making a call on SharePoint at the same time that the errors were occuring.

    A quick disable and stopping of the service showed that the errors stopped occuring.  So...if you have these tedious event id 1000 errors, don't forget to check on external monitoring services to see if they are the culprit, as SCOM was in my case.  It's nice to have a resolution to this. I thought I had stumped everyone at Microsoft.  Well...I guess I actually did stump them since I figured it out in the end.

     

  • Finally a hotfix for the Event ID 7076, 6398, and 6432 recurring errors!

    This is from a Microsoft support rep that has been working with me on these issues for quite a while now.  I know a lot of people have reported these problems, so I felt it worthwhile to spread the news:

    "Microsoft has now found the root cause of this problem to be the IIS ADSI provider. Essentially, if you have a process with more than one thread and two threads access IIS 6.0 at the same time, then this issue occurs.  This problem is likely to occur for the SharePoint Timer service (OWSTimer.exe) in Microsoft Office SharePoint Server 2007. When this occurs, you may find that:
    • In SharePoint Server 2007, tasks that are scheduled do not run.
    • When you try to manage IIS 6.0 by using Server Manager, you receive a blank page, or you receive the following error message: "the path specified cannot be used at this time".
    The Event ID's 7076, 6398 and 6432 and memory error messages described above will also be recorded in the Application Event Logs. Microsoft now has a KB article describing this problem http://support.microsoft.com/?id=946517 along with details of the fix and how to obtain it. This fix is not a SharePoint fix so you should be able to install the fix regardless of what Service Pack level you are running."
  • Knowledge Base application template - don't try to move it!

    I have come across a problem with the Knowledge Base application template for MOSS / WSS v3 that is easily reproducible.

    Summary of problem:  Links on the Knowledge Base site do not update to the new location when you import or restore the site from one location to another.

    Steps to reproduce: 

    1.  Create a site collection and top level site within it.

    2.  Create a new subsite, and use the Knowledge Base application template.

    3.  Backup the site using SharePoint Designer - or - export it using the STSADM -o export commands.

    4. Move or copy the resulting files to your other SharePoint 2007 environment.

    5. In the other SharePoint environment, create a site collection using the blank site template

    6. Restore the site using SharePoint Designer - or - import is using the STSADM -o import commands.

    7.  Browse to the site in the new location, and hover over the links in the quick launch for "Write an Article" or "Upload a Document".

    Both of those links will not have changed, and will be referencing a location and GUID from the old site.

    I hate having to tell my customers that they can create a site in development, but we can't move it to production for them.  Right now it seems to be that if you want to use the Knowledge Base template, you need to create it in its permanent location and never attempt to move it.

    I'd be interested to hear if anyone else has run into this problem, or if anyone has come across the solution or workaround for this?

    Thanks

    Share~A~Pint


Need SharePoint Training? Attend a SharePoint Bootcamp!

Posts (c) their respective authors. Everything else (c) 2007 SharePoint Experts