Today I thought it would be handy to have a machine kicking around that was not a MOSS install. That's right, some stock WSS. It's handy to have the both a WSS and a MOSS instance around so I can quickly compare and contrast the two. Sure enough I install all the dependencies, followed by a WSS with SP1 installation (Basic/Standalone). When I ran the SharePoint Products and Technologies Configuration Wizard though I got this crazy error!
I dug through the log that gets linked to during a failed configuration (those things are HUGE) and found a stack trace that looked like:
An exception of type System.Runtime.InteropServices.COMException was thrown.
Additional exception information: Could not access the Search service configuration database.
System.Runtime.InteropServices.COMException (0xC004122D): Could not access the Search service configuration database.
So it's looking for a Search Configuration database and can't connect...ok that's cool I guess. In the event log (Application) were a BUNCH of errors, but most of them were saying the same thing, "I can't connect to a database!". Here's a sample of an error taken out of the Event Log:
Event Source: Windows SharePoint Services 3 Search
Event Category: Gatherer
Event ID: 10036
Date: 2/28/2008
Time: 2:55:47 PM
User: N/A
Computer: W2K3-TYLER-WSS
Description:
A database error occurred.
Source: Microsoft OLE DB Provider for SQL Server
Code: 4060 occurred 1 time(s)
Description: Cannot open database "WSS_Search_W2K3-TYLER-WSS" requested by the login. The login failed.
Context: Application 'ca49badb-d82b-42b9-aaa1-ec2c3845c1b3'
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
So I decide to poke around. I install SQL Management Studio Express (free as in beer) on the machine and try to connect to the [ServerName]\OfficeServers edition. Low to my surprise, the WSS SQL Server instance is instead installed as Microsoft##SSEE (you can see this by running the Services Snap-in Start->Run->Services.msc look for SQL Server)! That's a new one. That EE stands for SQL Server Embedded Edition. What's even worse is you can't connect to the Embedded Edition instance via [ServerName]\Microsoft##SSEE. Instead you have to connect via a named pipe. Use the following server name to connect to the SQL Instance.
Finally we're getting close to an answer, essentially the Farm Accounts that need to connect to this database, NT Authority\Network Service and NT Authority\Local Service weren't added as users to this database! This is why the Configuration Wizard is kicking and screaming. It literally could not connect!
So I add the two accounts as dbo (dbowner) to the database instance that the event log was kicking and screaming about trying to connect too. Then we run the configuration wizard again and shazzam, the configuration wizard finished successfully. I guess all those log files actually have some useful information in them after all.
Hope this helps if you end up with a similar error.
Best,
Tyler
7 comments:
This is EXACTLY what was happening to me. I did what you said and it worked like a charm!
THANKS!
Thanks for the comment Bill. Feedback is the only thing that lets me know anyone reads this stuff (or that it helps anyone) :-).
Cheers!
We have the same problem and error message and posted it on the MS Private newsgroup, who pointed us at your solution. Unfortunately, having set up the security exactly as stated, the problem still exists and the wizard fails with the same error. We hve installed 3.0 with SP1 alongside 2.0 on a SBS 2003 server as recommended by MS. Any further advice would be appreciated.
Hey Roy,
I feel your pain man, these are a real pain to troubleshoot.
Are you sure that the errors you're getting are the same as those shown at the beginning of the blog? If so are you sure you've allowed the appropriate account access to to databases it's trying to get at? Consider using the Security part of the event viewer to see failed audits/login attempts in addition to what you see in the Application section of the event viewer.
I know I sound like a broken record but if your event log errors are indeed similar to mine the only fix I can think of is to ensure that you're giving the correct credential (Network Service, Local Service) the permissions it needs to connect and create databases.
If this is on a domain, remember that the farm credentials will probably be of the form DOMAIN\UserName.
Good luck,
Tyler
Thx for this post. Very helpful!!
I had this error tonight, but on a MOSS Single Server (Basic) installation (which is a stupid choice to make I know). Anyway, I really needed it, and it only went away when I noticed that with the Configuration Manager that only Shared Memory connections were enabled on the SQL Express instance. I enabled TCP and away it went to step 6. Only took me 5 hours to find it :(
when i run sharepoint products and technologies waizerd it falied sharepoint service . an expection of type System.Serviceprocess.Timeoutexception was thrwon.
How i can solve it
Post a Comment