SQL Logins and AD Accounts can bite
This one had me going for a while.
I was minding my own business doing a MOSS install. I successfully created the Office Server Search Service and onto the creation of the Shared Service Provider. Created the SSP and MySite Web Applications and then at the final step of creating the SSP, it bombed out after a long period of time with an error.
Reason: Windows NT user or group ‘MyDomain\MOSS_Search.service’ not found. Check the name again.
It then politely informed me that it would continue to try and provision the SSP while I correct this error.
It then sat in a state of ‘Provisioning’ and logged the following entry periodically in the application log (the full entry is pasted at the bottom of this post reference
Event Type: Error
Event Source: Office SharePoint Server
Event Category: Office Server General
Event ID: 7888
Date: 15/01/2008
Time: 12:02:45 PM
User: N/A
Computer: MYSERVER
Description:
A runtime exception was detected. Details follow.
Message: Windows NT user or group ‘MyDomain\MOSS_Search.service’ not found. Check the name again.
So off a hunting I went. I tried to stop and recreate the Office Server Search Service but that made no difference. Then I saw this thread that hinted the problem was with SQL maybe.
So I checked out SQL and immediately saw the problem. The person who created the MOSS_Search.service account had originally called it “MOSS _Search.service” by mistake (note the space). I realised this when I was configuring the Office Server Search Service and I had him change it back to “MOSS_Search.service”. But he did this just to the login and not the account name. (At least that’s my story and I’m sticking to it 🙂
So the account in AD was named “MOSS _Search.service” and the login name was “MOSS_Search.service”.
So when you set up a SSP, the Office SharePoint Server Search the search account is granted rights to the two SSP databases that are created on the SQL box. It looks like the SQL Login as created based on the User Name, rather than the login name, so we end up with a mismatch.
- SQL Login: MOSS _Search.service
- Connected AD Account: MOSS_Search.service
So much for GUID’s eh!
So in SQL Server, I renamed the SQL login to match the linked AD login name.
Fairly quickly, the event log stopped bleating and the SSP completed provisioning!
CleverWorkaround Rating: Grr! What’s the point of GUID’s then!
Seeya!
Event Type: Error
Event Source: Office SharePoint Server
Event Category: Office Server General
Event ID: 7888
Date: 15/01/2008
Time: 12:02:45 PM
User: N/A
Computer: MYSERVER
Description:
A runtime exception was detected. Details follow.
Message: Windows NT user or group ‘MyDomain\MOSS_Search.service’ not found. Check the name again.
Techinal Details:
System.Data.SqlClient.SqlException: Windows NT user or group ‘MyDomain\MOSS_Search.service’ 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.SharedDatabase.Microsoft.Office.Server.Administration.ISharedAccessControl.SetAccessControl(SharedComponentSecurity security)
at Microsoft.Office.Server.Search.Administration.SearchAdminUtils.GrantAccessToAccount(String username, ISharedAccessControl sharedAccessControl)
at Microsoft.Office.Server.Search.Administration.SearchSharedApplication.Install()
at Microsoft.Office.Server.Administration.SharedResourceProvider.ProvisionApplications(SharedComponentSecurity sharedApplicationSecurity)
at Microsoft.Office.Server.Administration.SharedResourceProvider.Microsoft.Office.Server.Administration.ISharedComponent.Install()
at Microsoft.Office.Server.Administration.SharedResourceProvider.Provision()
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
Leave a Reply