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

[2960 byte] By [Aspiff120] at [2008-1-1]
# 1
I have the same problem. Did you found any solution please?
Tittan at 2007-9-12 > top of Msdn Tech,SharePoint Products and Technologies,SharePoint - Setup, Upgrade, Administration and Operation...
# 2

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!!!

Andreas at 2007-9-12 > top of Msdn Tech,SharePoint Products and Technologies,SharePoint - Setup, Upgrade, Administration and Operation...
# 3
Well the domain name was an issue but it was in the SQL DB server not the Sharepoint Server.
Aspiff120 at 2007-9-12 > top of Msdn Tech,SharePoint Products and Technologies,SharePoint - Setup, Upgrade, Administration and Operation...
# 4

can u explain how did you solve this problem.

Thanks

Noordin at 2007-9-12 > top of Msdn Tech,SharePoint Products and Technologies,SharePoint - Setup, Upgrade, Administration and Operation...
# 5
Can you explain further please?
IRice at 2007-9-12 > top of Msdn Tech,SharePoint Products and Technologies,SharePoint - Setup, Upgrade, Administration and Operation...
# 6

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...

Aspiff120 at 2007-9-12 > top of Msdn Tech,SharePoint Products and Technologies,SharePoint - Setup, Upgrade, Administration and Operation...
# 7

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

AndrewKinloch at 2007-9-12 > top of Msdn Tech,SharePoint Products and Technologies,SharePoint - Setup, Upgrade, Administration and Operation...
# 8

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!!

RyutaM at 2007-9-12 > top of Msdn Tech,SharePoint Products and Technologies,SharePoint - Setup, Upgrade, Administration and Operation...
# 9

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.

YvesBoutemy at 2007-9-12 > top of Msdn Tech,SharePoint Products and Technologies,SharePoint - Setup, Upgrade, Administration and Operation...
# 10
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.

GabeM at 2007-9-12 > top of Msdn Tech,SharePoint Products and Technologies,SharePoint - Setup, Upgrade, Administration and Operation...

SharePoint Products and Technologies

Site Classified