2

I am having a bit of a strange issue. I am able to connect to the Central Admin page just fine but when I try to connect to any page on the site I get the following error.

Exception information: 
    Exception type: WebPartPageUserException 
    Exception message: Cannot connect to the configuration database. 

Request information: 
    Request URL: http://sharepoint/ 
    Request path: / 
    User host address: 
    User:  
    Is authenticated: False 
    Authentication Type:  
    Thread account name: sharepoint_service_b 

Thread information: 
    Thread ID: 10 
    Thread account name: sharepoint_service_b 
    Is impersonating: False 
    Stack trace:    at Microsoft.SharePoint.ApplicationRuntime.SPRequestModule.EnsureInitialize(HttpRequest request)
   at Microsoft.SharePoint.ApplicationRuntime.SPRequestModule.BeginRequestHandler(Object oSender, EventArgs ea)
   at System.Web.HttpApplication.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
   at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)


Custom event details:

This is occuring after I restored a site from a backup. The log seems to me like the account I am using can't be authenticated, but it is part of the WSS_ADMIn_WPG group, it can log onto the server just fine, and when logging onto the sql server it can see all the databases (including the configuration database) just fine.

Is there something obvious I am missing here?

-Mike

Improve this question
2
  • Do you get this error if you go to _layouts/settings.aspx on the restored site? Commented May 15, 2012 at 15:41
  • After a restart my original error seems to have gone away... the issue now it gives a 'Cannot complete this action' error with code 0x8004005. When I try to go to _layouts/settings.aspx it tells me I don't have access with any account I can think of Commented May 15, 2012 at 21:05

3 Answers 3

Reset to default
1

If the origin of the backup was in a different farm then it is possible that the application pool behind the web application that the DB was restored to might not have sufficient permissions to access the data. If the origin was in a different domain or used a different form of authentication then this is most definitely the case as user IDs are completely different across domains\authentication.

You will need to go into SQL and check the database permissions on the restored content database and compare the permissions there to other known-good databases in that farm.

You might also want to check the Site Locks and Quotas in Central Administration to make sure that the restored site isn't locked down that way.

If all else fails, go into Central Administration and add your domain account to the list of Site Collection administrators. This is not ideal but should let you get into the data

Improve this answer
0

Please check if all the SQL Services are running in the services manager.

Improve this answer
0

Ha Ha! I just had this problem - I could connect to SCA, but not my portal sites! I spent all day long with my portal down, looking through the logs and playing with the SQL authentication and poking through all the settings in SCA - and FINALLY discovered that somehow my ssl certificate had come loose from its binding in IIS.

I propose that you go to IIS, find your portal site, and go to "Basic Settings" and find your binding for ssl. Now, edit that, and make sure your ssl certificate is listed. It it is blank, that may very well be the problem.

However, I notice this question is from May, so, hopefully you already solved the issue!

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.