In my current quest to upgrade our MOSS farm to SP2, I have stumbled across some fairly nasty problems, first having to create a new configuration database, and now the content databases themselves won't re-attach.
If you experience the following message when running stsadm -o addcontentdb on a SP2 farm to attach an older content database and thus upgrade it, you will need to speak to Microsoft for a resolution.
"Cannot find the object "DatabaseInformation" because it does not exist or you do not have permissions."
If you wish to take a risk and fix the problem yourself, here is an unsupported resolution.
The problem you are having can be confirmed by expanding the tables of your content db and looking for the dbo.DatabaseInformation table. If this table is missing, that is why you can't upgrade your database.
This table contains a couple of columns (Name, Value), you need to re-create this table with exactly the same columns as in a working content database, and then generate a GUID with GUID Gen or similar. In the 'Name' column, type 'Id', in the 'Value' column enter a GUID string you have generated with GUID gen (or if you google guidgen there are online tools for this).
Now re-run the addcontentdb command and your database upgrade should complete.
Please remember this is unsupported.
Thursday, November 4, 2010
The specified SPConfigurationDatabase has been upgraded to a newer version of SharePoint. Please upgrade this SharePoint application server before attempting to access this object.
I am currently working on the task of upgrading our MOSS 2007 farm to SP2, and came across the following problem running psconfig (SharePoint Products and Technologies Wizard).
[SPConfigurationDatabaseSequence] [ERROR] [10/21/2010 1:01:41 PM]: Upgrade object too new (build version = 12.0.0.6327, schema version = 3.1.6.0). Current server (build version = 12.0.0.6421, schema version = 3.0.10.0).
[SPManager] [ERROR] [10/21/2010 1:01:41 PM]: CanUpgrade [SPConfigurationDatabase Name=SharePoint_Config Parent=SPDatabaseServiceInstance] failed.
[SPManager] [ERROR] [10/21/2010 1:01:41 PM]: The specified SPConfigurationDatabase Name=SharePoint_Config Parent=SPDatabaseServiceInstance has been upgraded to a newer version of SharePoint. Please upgrade this SharePoint application server before attempting to access this object.
The issue here is not to do with the service packs installed on any server in my farm, or any registry key settings, but the schema version of the configuration database. For MOSS 2007 this should always be 3.0.10.0 however in my case it is 3.1.6.0. The only probable explanation I have for this is a predecessor editing the database for some reason or other.
Unfortunately there is no supported method of dealing with this (you must never directly edit the SQL tables in SharePoint). Having spoken to Microsoft about this the only way forward is a fresh configuration database.
To do this, you will need to edit the registry key HKLM\Software\Microsoft\Shared Tools\Web Server Extensions\12.0\WSS\SetupType - change this from b2b to 'CLEAN_INSTALL'
When you next run the P&T Wizard you will be asked if you wish to disconnect from the farm, and you can then run the wizard a 2nd time to create a new farm.
This can also be achieved via psconfig cmd on the command console.
This doesn't pose too big a problem for a fairly savvy SharePoint administrator - just re-create all your web applications and use stsadm -o addcontentdb -url -databasename and this will upgrade your content databases as you attach them,
Obviously you will need to restore any SSPs, and reconfigure any farm level settings that you changed from defaults, as well as enable any features/custom code.
Review upgrade.log after each database attach to ensure there were no issues upgrading your content dbs.
I would be interested to hear from anyone else who has had this issue, to see if it was a hard edit in the database or an actual issue created by the software and is wider spread.
[SPConfigurationDatabaseSequence] [ERROR] [10/21/2010 1:01:41 PM]: Upgrade object too new (build version = 12.0.0.6327, schema version = 3.1.6.0). Current server (build version = 12.0.0.6421, schema version = 3.0.10.0).
[SPManager] [ERROR] [10/21/2010 1:01:41 PM]: CanUpgrade [SPConfigurationDatabase Name=SharePoint_Config Parent=SPDatabaseServiceInstance] failed.
[SPManager] [ERROR] [10/21/2010 1:01:41 PM]: The specified SPConfigurationDatabase Name=SharePoint_Config Parent=SPDatabaseServiceInstance has been upgraded to a newer version of SharePoint. Please upgrade this SharePoint application server before attempting to access this object.
The issue here is not to do with the service packs installed on any server in my farm, or any registry key settings, but the schema version of the configuration database. For MOSS 2007 this should always be 3.0.10.0 however in my case it is 3.1.6.0. The only probable explanation I have for this is a predecessor editing the database for some reason or other.
Unfortunately there is no supported method of dealing with this (you must never directly edit the SQL tables in SharePoint). Having spoken to Microsoft about this the only way forward is a fresh configuration database.
To do this, you will need to edit the registry key HKLM\Software\Microsoft\Shared Tools\Web Server Extensions\12.0\WSS\SetupType - change this from b2b to 'CLEAN_INSTALL'
When you next run the P&T Wizard you will be asked if you wish to disconnect from the farm, and you can then run the wizard a 2nd time to create a new farm.
This can also be achieved via psconfig cmd on the command console.
This doesn't pose too big a problem for a fairly savvy SharePoint administrator - just re-create all your web applications and use stsadm -o addcontentdb -url -databasename and this will upgrade your content databases as you attach them,
Obviously you will need to restore any SSPs, and reconfigure any farm level settings that you changed from defaults, as well as enable any features/custom code.
Review upgrade.log after each database attach to ensure there were no issues upgrading your content dbs.
I would be interested to hear from anyone else who has had this issue, to see if it was a hard edit in the database or an actual issue created by the software and is wider spread.
Subscribe to:
Posts (Atom)