Provisioning failed for SSP on Sharepoint 2007 STND

ChipShare (Default)
(Provisioning failed: Windows NT user or group 'CSI.com
\administrator' not found. Check the name again.)

I get this when I create my SSP. The SQL server and Sharepoint server
are in the same doamin running as a DOmain admin. The machines are
both 2003 and SQL is 2k SP3a...

I get this in the Application LOG

A runtime exception was detected. Details follow.
Message: Windows NT user or group 'csi.com\administrator' not found.
Check the name again.

Techinal Details:
System.Data.SqlClient.SqlException: Windows NT user or group 'csi.com
\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(TdsParserStateObje-ct
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.SynchronizeCo-nfigurationDatabaseAccess(SharedComponentSecurity
security)
at
Microsoft.Office.Server.Administration.SharedResourceProvider.SynchronizeAc-cessControl(SharedComponentSecurity
sharedApplicationSecurity)
at
Microsoft.Office.Server.Administration.SharedResourceProvider.Microsoft.Off-ice.Server.Administration.ISharedComponent.Install()
at
Microsoft.Office.Server.Administration.SharedResourceProvider.Provision()

For more information, see Help and Support Center at

SharePoint Products and Technologies3

I have the same problem. Did you found any solution please

I'm not sure but I suppose you have to write your domain name according to NetBIOS naming style, so if you have somedomain.com, you probably have SOMEDOMAIN as a NetBIOS domain name.

So you must write SOMEDOMAIN/administrator

Good luck!!!

Well the domain name was an issue but it was in the SQL DB server not the Sharepoint Server.

can u explain how did you solve this problem.

Thanks

Can you explain further please

OK here we go a little more detailed.

1st Make Sure all machines in the Farm can proerly join the domain and even list the SQL server to the AD if you want.

Make Sure you have rights to your SQL Server;

goto Enterprise Manger > Server> Security>Logins

Make sure the user form the domain you are loading the SSP with is in the list and a Sys Admin "Hell for now given all rights"

You can limit rights to the SQL Server later...

ok I had the same error but I found this which IMHO is a much tidier way of fixing it than altering the SQL server permissions.

so get yourself and account that does have permissions on the SQL server and run the following:

Central admin app pool ID - Database Access Account:
Make this change via the command line

stsadm.exe -o updatefarmcredentials -userlogin <DOMAIN\name> -password <password>

Thanks to Paul Edlund for his Blog post on that one

Though it doesn't understand whether to serve it

Therefore, not "test.com\Administrator" but "TEST\Administrator" set all the SQLServer access accounts.
Then, it lived well.

Good Luck!!

Hello,

I experienced the same symptom.

My diagnostic:
The user invoked in the SharePoint SSP creation is not in the list of "logins" of the SQL Server databases.

An explanation, for my case: I made a "clean up" of SharePoint. I am in a test phase of my project. I deleted all components of a first installation (sites, SSP, Web applications, central administration, server farm) but I did not uninstall SharePoint itself.
I renamed the service account under which the SharePoint sites run.

Now I recreate all components and I meet the problem.

Solution: I rename the service account in SQL Server logins. The SSP creation process finishs. Notice that in SQL Server databases, some objects (user in database) keep the name of the old service user but they are mapped with the renaned login object.

I've spent 2 days trying to figure this out too. For the sake of sharing info I'll add what I did but cannot guarantee it'll work for you.

I noticed that when I had to enter credentials for the service account created especially for the SSP, it gave me the error. I entered the account credentials in the format: domain and username (i.e. domain.com\username). I went back to Search Server Settings and re-entered the credentials for the farm search service account, only this time I entered it as domain\username (no .com). Seeing as I could not delete the default SSP, I created a new SSP and entered the account credentials in the latter format and where possible I used the people picker. This seemed to work for me and the SSP was created.

I Have tried all of the above and nothing has worked. I am close to formatting the server and starting over. I have changed the login for the services, ran the command line for changing the admin, tried to create ne SSP, recreated web apps... Every single time I get the same error and it always refers to the .com account.... I just dont know where else to change the login info. Is there a registry setting where is is being stored Can I just uninstall MOSS, IIS and start over again What would happen to the databases

Ok, so after long working on this, here is how it worked out:

(Pizza and Coffee ususally help.

- Deleted all Web Applications

- Deleted the SSP using:

stsadm –o deletessp –title yourSSPnamehere

- Recreated the Web apps using domain/user (no .com)

- Recreated the SSP

Worked!!!