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.

Advertisements

Required SQL Server Versions and Patch Levels for SharePoint 2010

Microsoft has been very clear about the requirements for installing SharePoint 2010. The biggest thing in this release is that it’s 64 bit only, not just on the Operating System side, but also in the SQL Server requirements. In addition, it’s also quite fussy about which versions it supports.

On the operating system side, a complete list can be found here. On the SQL Server side, it’s generally thought that it supports only SQL Server 2008 and above. However, this isn’t true – it supports SQL Server 2005 – provided that it’s 64 bit mode. However, the devil is in the details. It’s very specific about the patch level that you’re running. Glenn Berry has a list of the supported versions, with patch levels, and the SQL script for determining your precise version levels. There are only 3, so I’ll repeat them below:

  • SQL Server 2005 SP3 CU3 (Build 4220) or greater
  • SQL Server 2008 SP1 CU2 (Build 2714) or greater
  • SQL Server 2008 R2

The kicker is that neither the SP3 level of 2005, nor the SP1 level of 2008 will cut it,and you will have a failure if you do not conform to these versions. This failure will not appear until you run the SharePoint Products configuration wizard,which is pretty much past the point of commitment. In addition, the stsam.exe –o preupgradecheck command on a 2007 farm does not appear to detect this deficiency (at least it hasn’t yet in my experience).

Do yourself a favour, and patch up your SQL servers before you start your install/upgrade. The most recent cumulative update packages, as of this writing are:

I’ve used CU7 for 2008 on my installs thus far, and can attest that it works. I’m still waiting, hopefully not long now, for 2008 R2…