locked
log says that the login attempt was without a user id RRS feed

  • Question

  • Background: moss 2007, SP 2007 SP1. using sql server 2005

    The single farm has over 2000 subsites.

    We have had occasional cases of an event 5783 - shared services provider synchronization failed, with a reason of Timeout expired.  When I have investigated these, they generally took place during a time of load on the machine due to incremental backups of sharepoint site collections, etc.  One of the strange things, however, is that when I dig into the stack trace, the error is occuring due to a sql server timeout.

    Last night, the picture changed. We got a large number of these errors before incrementals even began. Also, in the event logs are not only errors about the sql server timing out, but also cases where the sql server could not be found.

    When I talked to the sql server guys, their logs were filled with failed logins from my machine - with the log saying that the login attempt was without a user id.

    No one has touched the Sharepoint configuration, and it is working just fine right now.  So there should be nothing that is attempting to access sql server without a login.

    I am wondering

    1) what specifically is the shared services provider synchronizing - what might be touched during that process?

    2) could a problem with active directory cause this type of behavior - I am wondering if there is a problem getting authentication credentials (we are using windows authentication between sharepoint and sql server)?

    3) what are some things I can do to figure out what is going wrong ?


    • Edited by Mike Walsh FIN Thursday, April 28, 2011 1:01 PM Trying to resolve + "strange" have not place in Titles. Title revised accordingly.
    Thursday, April 28, 2011 12:39 PM

All replies

  • Hi,

     

    According to your description, for your first question, when you meet with Event ID 5783, you need to try the following to solve your problem:

    stsadm -o sync -listolddatabases 1
    This gives us a list of databases that has not been syncronized for 1 day. You can change the values if you want to check further back in time.

    stsadm -o sync -deleteolddatabases 1
    This sounds scary right but it actually just deletes the record to the databases.
    Restart the Windows SharePoint Timer Service

    stsadm -o execadmsvcjobs

    The Second question, it is possible that you have entered your username and/or password incorrectly. I suggest that you should enter AD and make sure your account does not include the dashes or spaces.

     
    Best Regards
    David Hu

     

    Monday, May 2, 2011 1:31 AM
  • apart from David reply. Perhaps you can check with your SQL server guy if there any space issue for the transaction log <-- it happen to me alot last time where the transaction log eat our drive and causing authentication error.

    Monday, May 2, 2011 5:12 AM
  • Hi - I tried to follow these steps, and found the first command did not work for spsadmin. I had to log into the system as sa_sps to get it to work.

    Then I got:

    D:\temp>stsadm -o sync -listolddatabases 1

    Shared Service Provider Default Web Site
    No databases match the criteria for this Shared Service Provider

    D:\temp>stsadm -o sync -deleteolddatabases 1

    Operation completed successfully.

    D:\temp>stsadm -o execadmsvcjobs

    Executing .
    Executing job-watson-trigger.
    Operation completed successfully.

     

    I didn't understand your last point - I didn't enter the username and password. These were set quite some time ago, and work 99% of the time.  During the most recent events where we got the "missing" userid, we discovered that active directory was having difficulties and people were rebooting exchange servers, etc. to try and resolve things. 

    My theory is that since in most cases things are running as expected, either there is some login and password in sharepoint that is only used once every few weeks, or the issue is elsewhere.

    I just don't know how to _prove_ my theory.

    We haven't seen this condition come up again for a number of days now, which makes it tough to investigate the true nature of the problem. There are no event logs currently available with info relevant to the events.

    Thank you all for your ideas. I hope this problem is gone for the time being...

    Wednesday, May 4, 2011 11:37 AM
  • as an update, this problem continues to raise its head occasionally - like last night at 1:30am.  Still trying to figure out the culprit. It happens so infrequently that it seems unlikely that the problem is a missing login.
    Thursday, June 23, 2011 11:46 AM
  • Also, with regards to the kind suggestion about sql server transaction log space - I checked and today, at least, there's 67% disk space free for the transaction logs, which the sql server admin says will be plenty.  As before, the listolddatabases returns  a note that no databases match the criteria.
    Thursday, June 23, 2011 11:51 AM
  • A question for you. We had a series of event log entries during that 1:30am-1:45 or so period when the SSP was attempting to sync.

     

    Since this morning, the stsadm -o sync -listolddatabases 1 says that no databases match, does that mean that the SSP eventually was successful?

    Or could I start it from the command line, with flags that might tell me what is going wrong?

    I would just like to resolve this and I'm brainstorming for ideas.

    Thank you.

    Thursday, June 23, 2011 12:06 PM