• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 422
  • Last Modified:

Share Point / SQL Database

Hi,

I have 2 Sharepoint servers ( one web and one index/search ) on windows 2003 and 1 back end database server sql 2008.  I am having constant error message on both SQL

"Source MSSQLSERVER, Failure Aud Event ID 18456, User NT AUTH\SYSTEM, Computer:  SERVERNAME "

I came across a solution as follows on the net

" This is caused when an SSP has been deleted, SQL holds on to a job under "SQL Server Agents" tied to that "old" ssp that he might have removed.... Use SQL Management Studio, connect to the db, find SQL server agents and then expand jobs...  You should have lost the index if the SSP went bad, no worries..

Here you'll need to know the name of your old Shared Service Provider DB... Looks for something like SSPNAMEHERE_DB_DeleteExpiredSessions... If you're sure that's not in use you can either delete or disable the job and the errors will halt."

can somebody tell me what SSP and how to check it,

i attach the sql agent jobs

Thanks
0
toronto2456
Asked:
toronto2456
  • 7
  • 5
1 Solution
 
CloudedTurtleCommented:
I don't think that anyone could tell you which SSP. As they can be setup and named differently. The Default SSP is usually named "Default SSP".

My Recommendation would be to login to Central Admin and look at the SSPs that are listed there. Then open SQL Server Management Studio and confirm the DBs for the SSPs listed in Central Admin. Then disable the SQL Job for any that don't match up.

Hope that helps.
0
 
toronto2456Author Commented:
Thanks
0
 
toronto2456Author Commented:
i am having problems with these servers. and i saw that one of the jobs has been configured to use wrong credentials..

do you think this can cause this problem to happen and lastly i am thinking to bring the servers uptodate to see if it can solve the issue.

do you have any recommendation how to do it ? how can i figure out my current patch level with sharepoint

thanks
0
Concerto's Cloud Advisory Services

Want to avoid the missteps to gaining all the benefits of the cloud? Learn more about the different assessment options from our Cloud Advisory team.

 
CloudedTurtleCommented:
I would recommend updating the credentials first and determine if that fixes your problem.

I personally don't like to update to "see if it fixes a problem" unless I know before hand that it will resolve the issue. If you environment was stable prior, I like to ensure that it is stable before applying any updates.

To figure out your current patch level,  you should log into Central Admin, and click the "Operations" tab. Then select the "Servers in Farm" from there you should see each server, and the version of SharePoint that is running. Here is a blog that describes it, along with a list of version/update numbers. If your version isn't listed, you will just have to google your version. (these lists are very hard to find with the most recent version number..)

Here is where you can easily locate any updates you may need (up to the most recent update)
0
 
toronto2456Author Commented:
i definitely agree with you. I changed the credentials to sa to be sure and just waiting now.

our sharepoint site keep going down every 4-5 days and as a temporary solution, we restart the sql server services. So since this sql job cant access the server because of wrong credentials, it might be the issue. But i am not sure how restarting sql server service solves the issue.

thanks for the info
0
 
toronto2456Author Commented:
MOSS 2007 SP1 (KB936984, KB942390)       December 11, 2007       12.0.0.6219
WSS 3.0 SP1 (KB936988, KB942388)       December 11, 2007       12.0.0.6219

here it seems i am at SP1.

Actually I am agree with you that before knowing the real reason i don't want to go with update. the only reason i am thinking update is the fact that the other problem we are having seems to have same semptoms with error message with one article.

    Event ID 6398
    Event ID 6482
    Event ID 7076

and the hot fix are in the SP3.

KB Article Number(s): 946517
Language: English
Platform: x64
Location: (http://hotfixv4.microsoft.com/Windows%20Server%202003/sp3/Fix220121/3790/free/335450_ENU_x64_zip.exe)
0
 
CloudedTurtleCommented:
If there is another problem that is resolved by applying the updates, then you should apply the updates. However, the problem that you described above doesn't appear to have anything to do with that KB. I would recommend that you resolve 1 issue at a time, as you are more likely to prevent introducing additional issues or uncovering issues that we didn't see before.

Depending on the type of Job that SQL is running, it could be possible that it started (maybe brought the server instance off-line, or marked your DBs as "locked" to prevent any new changes) and then never properly recovered if it had an error. Restarting the SQL Server would remove any locks on the DBs allowing proper access. At least until you job runs again.
0
 
toronto2456Author Commented:
I see you point.

I am not familiar with sharepoint, but the job, named shared services reorg sub plan,  that's configured with wrong credentials runs once a week and of course it can't run.

it is my understanding that if something wrong with the configuration or accessibility with the servers , then problem should be persistent. but in my case, restarting sql service will solve the issue for some time, as if something keep piling up underneath and then crash the site.
0
 
CloudedTurtleCommented:
Can the correlation between when the job runs be tied to when the server fails? If your server is failing after the job runs then we definitely have a correlation.

You could try manually running the job when you know the server is responding properly and see if it still works after the job has finished running (or fails.) At least then you would know where your point of failure is.
0
 
toronto2456Author Commented:
Thanks for the info. Since the credential was wrong, job never ran if i understand correctly.

job runs once a week and site goes down more often than that,

What i am thinking is that since this job is supposed to run once in every weekend, and it has not been running , that might be the issue. It seems to me that ( just idea , i don't know share point  ) since job is not running, that is causing something accumulated and after reaching at certain threshold, it causes the site down and restarting the sql server service just empty whatever accumulating ,  

just an idea :)

thanks for your input again
0
 
CloudedTurtleCommented:
If the job is truncating transaction logs, and doing some overall maintenance on the SharePoint content DBs then you most certainly could be right. it is a best practice to do some clean up regularly to prevent the DBs from growing too large and choking out the server.

Hope you are eventually able to resolve this issue.

Keep us all posted.
0
 
toronto2456Author Commented:
thanks, I will look at that and probably will run the job . I know that job itself is doing some tasks on Sharepoint DBs, and as far as I remember it is some indexing related stuff, i will look at the TSQL  in the job.

there are error messages like these all the time recurring error messages:

    Event ID 6398
    Event ID 6482
    Event ID 7076
 
and the other thing that makes me confused is that in the following error message on the SQL server,

"Source MSSQLSERVER, Failure Aud Event ID 18456, User NT AUTH\SYSTEM, Computer:  SERVERNAME "

the servername is the ip adress of the one of the sharepoint servers. This also seems to tell me that this access problem is intermittent not permanent,  that confuses me as it means it is not permission or auth related problem, otherwise it wont let moss site running after starting sql service

but that not running job might be the root cause of all of this as you say

Thanks,, will keep update as it seems a common problem.
0

Featured Post

Efficient way to get backups off site to Azure

This user guide provides instructions on how to deploy and configure both a StoneFly Scale Out NAS Enterprise Cloud Drive virtual machine and Veeam Cloud Connect in the Microsoft Azure Cloud.

  • 7
  • 5
Tackle projects and never again get stuck behind a technical roadblock.
Join Now