Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am building a SharePoint test farm with SharePoint server 2007 Enterprise based on Windows Server 2008 R2. There are 3 different virtual machines (Hyper-V), all in the same domain, UCTEST. When I installed SharePoint and ran the configuration wizard, I entered a domain account (svc_sp) as the main farm / central account, which worked perfectly.

Now, in Central Admin, I try to go through the administrators tasks list, and in the assign services to servers task I try starting the Windows SharePoint Services Search service. I enter 2 separate user accounts for the search and content access parts. The user's exist and are in the same organisational unit as the main farm account. But when I click start I get an Event ID 4625, audit failure.

The error message is the following:

An account failed to log on.


Security ID: UCTEST\Administrator

Account Name: Administrator

Account Domain: UCTEST

Logon ID: 0x98828

Logon Type: 3

Account For Which Logon Failed:

Security ID: NULL SID

Account Name: svc_sp_wsscontent

Account Domain: UCTEST

Failure Information:

Failure Reason: Unknown user name or bad password.

Status: 0xc000006d

Sub Status: 0xc000006a

Process Information:

Caller Process ID: 0x364

Caller Process Name: C:\Windows\System32\inetsrv\w3wp.exe

Network Information:

Workstation Name: UCTEST-UC01

Source Network Address: -

Source Port: -

Detailed Authentication Information:

Logon Process: Advapi

Authentication Package: Negotiate

Transited Services: -

Package Name (NTLM only): -

Key Length: 0

P.S. Thinking it could be SQL related i have made all service account securityadmin and dbcreator on SQL Server (2008 SP1)

P.P.S. All users needed are added to the "logon as batch" / "logon as service" in the local security group policy.

share|improve this question
are you specifying service account names the form of uctest\service_account_name? – shufler Sep 4 '09 at 17:26
Yes, fully qualified usernames – Colin Dekker Sep 4 '09 at 23:18
up vote 1 down vote accepted

Deleting the user accounts and recreating them seemed to do the trick. Tried logging on to the machine as the service account didn't work, so i figured there had to be something wrong with the account. deleted it, added it, now it's all working again..

share|improve this answer
Another thing you might have tried in SCA to go to Managed Accounts and reset the password for the managed service application. If you find that your application pool consistently quits when you access a page, this is usually what fixes that. – bgmCoder Nov 6 '14 at 21:11

Check SQL Server to see if the svc_sp_wsscontent account has a mapping to the appropriate databases.

share|improve this answer
It is in the securityadmin / dbcreator server role, it shouldn't need any mapping. Furthermore, the only db's created are the config / central admin content db's – Colin Dekker Sep 4 '09 at 16:37

By default local administrators have rights to access Central Administrator, but they do not necessarily have full control over everything.

Try logging into Central Admin with the farm account (svc_sp) or grant uctest\administrator farm administrator rights (Central Admin -> Operations -> Farm Administrators).

share|improve this answer
tried that already, this is going wrong on the windows level, not sharepoint. – Colin Dekker Sep 4 '09 at 16:51
then there is always the official documentation: Talks about all the accounts you can set up, and what rights on the server, in the db, and the in the domain they need. – shufler Sep 4 '09 at 17:22

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.