Skip to content

Tag: Event 3760

SharePoint Loses Access to Central Admin Content Database

I had a nasty problem with a client today that was running SharePoint 2007. They were doing some SQL database maintenance and inadvertently wound up with some problems with their msdb system database. They were able to get these rebuilt, and SharePoint appeared to work just fine. However, when I attempted to access the Central Administration application, I received the highly instructive “Unknown Error”.

The event log of course had a string of errors in it, most of which were Event 3760, with details below:

Cannot open database “SharePoint_AdminContent_ae0bba59-2a40-4110-8e9b-de1dcbbefc1f” requested by the login. The login failed. Login failed for user ‘xxxxxxxxx’.

SQL Server logs were also showing that access was denied, but the service account in question not only had all of the correct SQL roles, it was also the DB owner. This was obviously not actually a permissioning problem. The user could connect through SQL Management Studio, etc.

My next attempt at a solution was to remove, and re-add the Central administration application from the server using the Products and Technologies configuration wizard. That didn’t help at all, as it was simply  referring to the same database, The problem obviously existed within SQL Server itself.

I could have removed the server from the farm,but that wasn’t something that I wanted to deal with,and the client wanted to prevent any more down time than was absolutely necessary. What finally worked was to create a new SQL database from a backup of the old one, and then configure Central Administration to use it. This also had the side benefit of removing the only remaining database in the farm with a GUID in its name.

The exact steps required to do this were:

  1. Take a full SQL backup of the Administration Application content database.
  2. Run stsadm –o deletecontentdatabase –url http://myurl:myport –databasename olddatabasename
  3. Run SQL Management Studio and Detach the old content database. Either delete it, or move it to a new location. Don’t forget to do the same with the transaction logs
  4. Restore the content database backed up in 1 to a new name (preferably without GUIDS). Watch the filenames (under the options tab) and use the overwrite option
  5. Run stsadm –o addcontentdatabase –url http://myurl:myport –databasename newdatabasename

You should be good to go after this. This procedure also works if you just want to rename your Central Admin content database.

Leave a Comment