Hey,I have a MOSS server that every minute records a new error in the event logDetails is below.I seems to be a sql access issue, but I cannot find the process that makes the call to the sql server.(it's a sql 2005 server)I have checked that all web applications use a domain account to access the sql server.The most strange thing is actually that nothings seems to be broken.. all websites is running and nobody is complaining... but still it would be nice to get this thing out of my event logIf anyone has ideas I will appreciate it.Der blev registreret en krselsundtagelse. Detaljerne flger. Meddelelse: Windows NT user or group 'SERVERNAME\administrator' not found. Check the name again.Tekniske detaljer:System.Data.SqlClient.SqlException: Windows NT user or group 'AASEXTMOSS01\administrator' not found. Check the name again. at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection) at System.Data.SqlClient.SqlInternalConnection.OnError(SqlException exception, Boolean breakConnection) at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj) at System.Data.SqlClient.TdsParser.Run(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj) at System.Data.SqlClient.SqlCommand.FinishExecuteReader(SqlDataReader ds, RunBehavior runBehavior, String resetOptionsString) at System.Data.SqlClient.SqlCommand.RunExecuteReaderTds(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, Boolean async) at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method, DbAsyncResult result) at System.Data.SqlClient.SqlCommand.InternalExecuteNonQuery(DbAsyncResult result, String methodName, Boolean sendToPipe) at System.Data.SqlClient.SqlCommand.ExecuteNonQuery() at Microsoft.Office.Server.Data.SqlSession.ExecuteNonQuery(SqlCommand command) at Microsoft.Office.Server.Data.SqlServerManager.GrantLogin(String user) at Microsoft.Office.Server.Administration.SharedResourceProvider.SynchronizeConfigurationDatabaseAccess(SharedComponentSecurity security) at Microsoft.Office.Server.Administration.SharedResourceProvider.SynchronizeAccessControl(SharedComponentSecurity sharedApplicationSecurity) at Microsoft.Office.Server.Administration.SharedResourceProvider.Microsoft.Office.Server.Administration.ISharedComponent.Synchronize()For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

Open up SQL Management Studio and take a look under Security and Logins. What level access is the user 'SERVERNAME\administrator' set to? John SharePoint911: SharePoint Consulting http://www.sharepointblogs.com/rossonmoss

Hi, I think that you could help me because I have a similar problem, and I don't know where I can attack itEvent Type: ErrorEvent Source: Office SharePoint ServerEvent Category: General de Office Server Event ID: 7888Date: 4/24/2008Time: 12:59:51 PMUser: N/AComputer: SHRPOINTSRVDescription:Se ha detectado una excepcin en tiempo de ejecucin. Detalles. Mensaje: 'sharepointuser' is not a valid Windows NT name. Give the complete name: <domain\username>.Detalles tcnicos:System.Data.SqlClient.SqlException: 'sharepointuser' is not a valid Windows NT name. Give the complete name: <domain\username>. at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection) at System.Data.SqlClient.SqlInternalConnection.OnError(SqlException exception, Boolean breakConnection) at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj) at System.Data.SqlClient.TdsParser.Run(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj) at System.Data.SqlClient.SqlCommand.FinishExecuteReader(SqlDataReader ds, RunBehavior runBehavior, String resetOptionsString) at System.Data.SqlClient.SqlCommand.RunExecuteReaderTds(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, Boolean async) at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method, DbAsyncResult result) at System.Data.SqlClient.SqlCommand.InternalExecuteNonQuery(DbAsyncResult result, String methodName, Boolean sendToPipe) at System.Data.SqlClient.SqlCommand.ExecuteNonQuery() at Microsoft.Office.Server.Data.SqlSession.ExecuteNonQuery(SqlCommand command) at Microsoft.Office.Server.Data.SqlServerManager.GrantLogin(String user) at Microsoft.Office.Server.Administration.SharedResourceProvider.SynchronizeConfigurationDatabaseAccess(SharedComponentSecurity security) at Microsoft.Office.Server.Administration.SharedResourceProvider.SynchronizeAccessControl(SharedComponentSecurity sharedApplicationSecurity) at Microsoft.Office.Server.Administration.SharedResourceProvider.Microsoft.Office.Server.Administration.ISharedComponent.Synchronize()For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

Hi I hope this helps.I had the exact same problem and I went into my SQL Server 2005, in the management studio, went to the security folder under the SQL server Instance, and went to logins and noticed that my service account (mydomain\mysharepoint_service account) was only granted public access for the "Server Roles" in the service account "Properties"this account must be given db_creator and securityadmin roles as well.That should fix this problem for you.Also, this problem only developed for me when I decided to create a new service account and use it in replace of the existing account I used to originally install MOSS 2007.Luckily this was a testing environment for me, but I have learned that you must even have service accounts planned out foruse when planning to install and configure MOSS 2007.That should fix your problem.Network Analyst

If you look at the bottom of the stack trace you can see that there's a timer job specific to the SSP which is trying to grant a service account access (SynchronizeAccessControl and GrantLogin)to the configuration database (SynchronizeConfigurationDatabaseAccess). What you need to do is verify what service accounts your SSP is using. This particular account is most likely a local admin account (not a domain account) so the sql box can't locate it (assuming that aasextmoss01 is not your domain name but rather your server name). Locate where that account is used and fix that to be a domain account and you should be okay (check your services, profile import account, default content access account, excel services unattended access account, search service account, app pools, etc.).

Hi,I have same eventID but different issues i guese. below are the details A runtime exception was detected. Details follow. Message: Cannot insert duplicate key row in object 'dbo.UserMemberships' with unique index 'CX_UserMemberships_RecordId_MemberGroupId_SID'.The statement has been terminated.this happen every 1 minute with eventid 5553. there is no problem in MOSS and everything running well. but it annoying to see this error on the event log

In my case it was a local admin account which was listed as process account in the ssp properties.When i replaced this process account by another domain account (just removing did not work somehow.. i had to remove and type something else)I was trying to fix the error access denied on user profiles and properties but that was fixed by changing the permissions for that._layouts/ManageServicePermissions.aspx of the ssp admin site (thanks to blog entry of Jonh stover (http://www.stovereffect.com/?tag=/sharepoint)

1) There are numerous timer jobs that MOSS 2007 uses to perform scheduled tasks. Since you are getting this error once per minute, it means that one of your timer jobs that runs once per minute is running with invalid credentials. If you are aware that the credentials shown in the error message are incorrect, then you now have to figure out which timer job is causing the problem, and figure out how to update the credentials for that timer job. If you believe the credentials used are correct, then you need to check your SQL DB configuration, permissions, and settings to make sure that the user has the right permissions. Note SQL can be configured to work with windows authentication or SQL authentication or both. 2) In my specific case, the credentials were invalid credentials that I needed to update somehow. Descriptions of some timer jobs: http://blogs.msdn.com/b/gregmcb/archive/2008/03/05/ssp-and-owstimer-service-job-descriptions-used-for-synchronization.aspx Updating accounts: http://support.microsoft.com/kb/934838 I had updated the information in the following with no luck: Operations -> Data Configuration-> Default Database Settings Operations -> Security Configuration -> Service Account The following command synched things up for me: stsadm -o updatefarmcredentials -userlogin DomainName\UserName -password NewPassword PS. I actually read another article elsewhere about one of the timer jobs in SQL Agent causing the issue. There was a timer job from a previously deleted Shared Service Provider that was lingering there. The user just had to figure out whiich of the two was the culprit by disabling the suspect one and seeing if the errors stopped. http://fredmorrison.wordpress.com/2009/03/17/sql-server-job-schedule-needs-to-be-disabled-after-rebuilding-moss-2007/. That didn't apply to my case, though.

1) There are numerous timer jobs that MOSS 2007 uses to perform scheduled tasks. Since you are getting this error once per minute, it means that one of your timer jobs that runs once per minute is running with invalid credentials. If you are aware that the credentials shown in the error message are incorrect, then you now have to figure out which timer job is causing the problem, and figure out how to update the credentials for that timer job. If you believe the credentials used are correct, then you need to check your SQL DB configuration, permissions, and settings to make sure that the user has the right permissions. Note SQL can be configured to work with windows authentication or SQL authentication or both. 2) In my specific case, the credentials were invalid credentials that I needed to update somehow. Descriptions of some timer jobs: http://blogs.msdn.com/b/gregmcb/archive/2008/03/05/ssp-and-owstimer-service-job-descriptions-used-for-synchronization.aspx Updating accounts: http://support.microsoft.com/kb/934838 I had updated the information in the following with no luck: Operations -> Data Configuration-> Default Database Settings Operations -> Security Configuration -> Service Account The following command synched things up for me: stsadm -o updatefarmcredentials -userlogin DomainName\UserName -password NewPassword PS. I actually read another article elsewhere about one of the timer jobs in SQL Agent causing the issue. There was a timer job from a previously deleted Shared Service Provider that was lingering there. The user just had to figure out whiich of the two was the culprit by disabling the suspect one and seeing if the errors stopped. http://fredmorrison.wordpress.com/2009/03/17/sql-server-job-schedule-needs-to-be-disabled-after-rebuilding-moss-2007/. That didn't apply to my case, though.

1) There are numerous timer jobs that MOSS 2007 uses to perform scheduled tasks. Since you are getting this error once per minute, it means that one of your timer jobs that runs once per minute is running with invalid credentials. If you are aware that the credentials shown in the error message are incorrect, then you now have to figure out which timer job is causing the problem, and figure out how to update the credentials for that timer job. If you believe the credentials used are correct, then you need to check your SQL DB configuration, permissions, and settings to make sure that the user has the right permissions. Note SQL can be configured to work with windows authentication or SQL authentication or both. 2) In my specific case, the credentials were invalid credentials that I needed to update somehow. Descriptions of some timer jobs: http://blogs.msdn.com/b/gregmcb/archive/2008/03/05/ssp-and-owstimer-service-job-descriptions-used-for-synchronization.aspx Updating accounts: http://support.microsoft.com/kb/934838 I had updated the information in the following with no luck: Operations -> Data Configuration-> Default Database Settings Operations -> Security Configuration -> Service Account The following command synched things up for me: stsadm -o updatefarmcredentials -userlogin DomainName\UserName -password NewPassword PS. I actually read another article elsewhere about one of the timer jobs in SQL Agent causing the issue. There was a timer job from a previously deleted Shared Service Provider that was lingering there. The user just had to figure out whiich of the two was the culprit by disabling the suspect one and seeing if the errors stopped. http://fredmorrison.wordpress.com/2009/03/17/sql-server-job-schedule-needs-to-be-disabled-after-rebuilding-moss-2007/. That didn't apply to my case, though.

in my case, the search service account was not added to a newly created web application content db. the Stefan Gordon's Sharepoint ULS viewer is a good tool to find this.

in my case, the search service account was not added to a newly created web application content db. the Stefan Gordon's Sharepoint ULS viewer is a good tool to find this.