3


I have reviewed all posts related to my issue but nothing seems to work yet.

I'm working with SHP2010 and I'm getting the classic:
Cannot connect to the configuration database while trying to connect to the Central Admin.

The LOG says:
Cannot open database "SharePoint_Config" requested by the login...

But I'm not being able to grant permissions to my user since the DataBase seems to be in a readonly state. (although I'm an Administrator)

enter image description here

More information:

  • I've tried it with all Administrator users.
  • All Windows Services are running (shpAdmin, shpTimer, all MSSQLSERVER services)
  • I've restarted all services listed above and also did IIS-reset.
  • I've tried to re-run Sharepoint Wizard and I'm getting same permission error.
  • When I open Sharepoint 2010 Management Shell as Administrator, I have the following message: The local farm is not accessible. Cmdlets with FeatureDependencyId are not registered.
  • Psconfig.exe -cmd upgrade -inplace b2b -wait -force gives me the same permission error.

Any thoughts?
Thanks in advance!
Andrés.

  • It is important that the farm admin account has permissions on the database. Can you open the central administration? Does the farm account has permission on the sharepoint_config database? How is the state of the database? What have you done pefore you get ran into this problem? – BOG Dec 18 '15 at 19:11
  • 1
    This looks like a SQL Server issue rather than a SharePoint issue. Can you validate that the SQL Server service account has access to the MDF and LDF for the SharePoint_Config database? – Trevor Seward Dec 18 '15 at 19:15
  • @STORM I can't open the CA, neither see the DataBase config. It's a development environment that I hadn't used for a long time. Nothing relevant happened (at least that I have noticed). – klewgenius Dec 23 '15 at 13:44
  • @TrevorSeward - while I agree about the "SQL server related" part, I think it is still pretty useful to keep this question here. The important part isn't the fact that the db went "corrupted", it is the fact that SharePoint behaves this way when it does. Probably you didn't mean to mark this as offtopic, but I wanted to point this out just in case. – BlueSoul Dec 23 '15 at 19:42
1

If the database seem to be "readonly" as you say, I think it may have been put in "Suspect" state after some issue occurred on the machine. When SQL Server thinks a database may have entered an invalid state, the "Suspect" state may be triggered - I had it once happen on a development virtual machine that was turn down during a web application creation and the results were the same you describe - an inaccessible Central Admin.

Try to confirm that the database is still working correctly. If this is not the case, you may want to try to recover it with some external tool. Microsoft also provides some basic recovery functions that may help in some situations, but you should have some more advanced tool ready - especially if the database contains some important data you cannot afford to lose.

0

Finally I was able to fix my problem.

Following your suggestions, I was checking if my database was in a SUSPECT mode and I realized that it was in a RECOVERY_PENDING status.

I tried a lot of things but these two post were very useful:

  1. Using EMERGENCY mode to access a RECOVER_PENDING database
  2. EMERGENCY mode, repair example

Summarizing:

  1. Check database status:
    SELECT DBName=NAME, [Status]=state_desc FROM sys.databases

enter image description here

  1. ALTER DATABASE SharePoint_Config SET EMERGENCY;
  2. ALTER DATABASE SharePoint_Config SET SINGLE_USER;
  3. DBCC CHECKDB (N'SharePoint_Config', REPAIR_ALLOW_DATA_LOSS) WITH ALL_ERRORMSGS, NO_INFOMSGS;
    Please note that in my case I was working in a Development Environment where there's nothing important to lose.
  4. ALTER DATABASE SharePoint_Config SET MULTI_USER;

My Central Administration is working again! I really appreciate your help, thank you guys!

  • Yep - that was the general idea. I was going to add the information about the emergency node but didn't have the time to, pretty busy during these days. Glad you were able to find them out on your own. – BlueSoul Dec 23 '15 at 19:40
  • 1
    Note that using REPAIR_ALLOW_DATA_LOSS is not supported with SharePoint. It's best just to abandon the database at that point and restore from backup, regardless of development environment or not. – Trevor Seward Dec 23 '15 at 20:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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