Guys, This is the farm configuration: 1. SQL Server 2005 back end server 2. WSS 3.0 / MOSS 2007 WFE Server 3. WSS 3.0 / MOSS 2007 Index/WFE Server All servers are showing the version: 12.0.0.6327 in 'Servers in Farm' in C.A. When attempting to add a new content database, the following error is thrown in the web UI: The specified SPConfigurationDatabase Name=SharePoint_Config-New Parent=SPDatabaseServiceInstance has been upgraded to a newer version of SharePoint. Please upgrade this SharePoint application server before attempting to access this object. Furthermore the following is posted to the application event log on the WFE hosting central admin: Database 'SharePoint_Config-New' on SQL Server instance 'XXXXXXXX' is not empty and does not match current database schema. There is nothing of further interest in the trace log, just the same error as above. No errors on the SQL server either. Also no updates have been installed, and content databases HAVE been created since the last updates were installed 2 years ago. Can anyone suggest anything before I raise a call with MS? I have checked permissions for the sharepoint system account on the databases and all seems fine. Cheers, Conrad Conrad Goodman MCITP SA / MCTS: WSS3.0 + MOSS2007

Whilst it may appear that some updates have installed, I've analysed the servers in detail and it appears a content db has been created a year ago, which is months after any updates were last installed. What is interesting however, is that the main WFE server has WSS 3.0 SP1 installed, as well as MOSS 2007 SP1, the indexer and other WFE server only have WSS 3.0 SP1 installed and no MOSS 2007 SP1. This aside, the farm version number 12.0.0.6327 does not include ANY of these service packs. I have run a query against the SQL server, and the versions of the databases is being returned as 12.0.0.6327 for both the SharePoint_Config and the content dbs. This does not correspond with what the error message states, i.e. the configuration db has been upgraded and the servers have not, everything appears to be of the same version, regardless of various service packs have been installed (but apparently the farm version hasn't been upgraded, possibly because the binaries have been installed but the dbs haven't been upgraded with the products and technologies wizard). I get the same error when trying to add a content db through stsadm on any of the WFE servers (and they all have WSS 3.0 SP1 on them but not showing this in the farm version/server version in C.A.) What is really getting me is my predecessor has created a content db a 18 months ago, which is months after any of these updates were installed on the servers. I think perhaps I need to install the rest of the binaries (MOSS 2007 SP1) on the remaining 2 WFE servers, and then run the products and technologies wizard to upgrade all the DBs. Or would uninstalling WSS 3.0 SP1 and MOSS 2007 SP1 binaries be a solution? I look forward to any further responses! Cheers, ConradConrad Goodman MCITP SA / MCTS: WSS3.0 + MOSS2007

Ivan, Your suggestions are in line with what I'm planning to do on the 'test' environment once I get the hardware to test it. With thousands of users hitting the WFE's I can't afford to take anything down and have to do restores. I have already done as you suggest against the config database as I said in my previous post I've quered the SQL server and the version of the config DB matches the server versions exactly. As does the version of the content dbs I've checked with the same query. I have now just had a further revelation! If I create a new web application, the creation of the database along with the web application executes without any problems at all! This is the same process that was used to create the last content db, so this error has never been uncovered before as noone has tried to just create a content db without creating a fresh web application at the same time. I have no idea however why it will create a content db with a web app, but not on it's own! Cheers, ConradConrad Goodman MCITP SA / MCTS: WSS3.0 + MOSS2007

Ivan, I wasn't aware of that registry key - thanks for that! Main WFE shows version: 12.0.6219.1000 Index WFE shows version: 12.0.4518.1016 old WFE shows version: 12.0.4518.1016 I'm guessing this corresponds with the fact they have different SharePoint binaries installed? i.e. the 1st has WSS SP1 and MOSS SP1, the 2nd and 3rd have WSS 3.0 SP1 only. Cheers, ConradConrad Goodman MCITP SA / MCTS: WSS3.0 + MOSS2007

Ivan, have you any further suggestions, or do you think installing all the binaries and psconfig is the way to go.Conrad Goodman MCITP SA / MCTS: WSS3.0 + MOSS2007

Ivan, Just to clarify I would first install WSS 3.0 then MOSS SP2 on all my 3 WFEs I would then run psconfig.exe -cmd upgrade -inplace b2b-wait until the operation completes on the 1st server, then repeat on 2nd and 3rd WFEs? Then do the same with the August CUs? Conrad Goodman MCITP SA / MCTS: WSS3.0 + MOSS2007

Ivan/Everyone I've had to unmark the above post as the answer, as I still have this issue! I've attempted to install all SP2 binaries, and run the psconfig commands as suggested, and have the following issue: Approach 1: Install SP2 binaries on all servers, run PSCONFIG. 1. Detach all content databases in Central Administration a. Issues detaching some content databases (conflict error) need to clear url cache on WFEs. b. DO NOT detach Central Admin content db 2. IISRESET /stop on WFEs 3. Install WSS 3.0 SP2 on WFEs 4. Install MOSS 2007 SP2 on WFEs 5. Run PSCONFIG a. Error: SharePoint_Config-new database is too new: [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-New Parent=SPDatabaseServiceInstance] failed. [SPManager] [ERROR] [10/21/2010 1:01:41 PM]: The specified SPConfigurationDatabase Name=SharePoint_Config-New Parent=SPDatabaseServiceInstance has been upgraded to a newer version of SharePoint. Please upgrade this SharePoint application server before attempting to access this object. It would appear the Schema version of my configuration database is higher than the one of the current server - how can this possibly be? I've also tried the following approach: Approach 2: Install current farm level updates, run PSCONFIG Current farm version is 12.0.0.6347 (SP1 with August 2008 CU). However AP-07 is showing just SP1 in version number in registry, and AP-04 is showing just RTM version number with no service packs. This approach looks at installing the matching service packs and CUs to the content/config db versions and running the PSCONFIG wizard. 1. Install MOSS SP1 x86 on AP-04 2. Install WSS 957109 August CU on AP-04 3. Install MOSS 956056 August CU on AP-04 4. Run PSCONFIG on AP-04 5. Run PSCONFIG on AP-07 Thithis approach results in the same error: [SPConfigurationDatabaseSequence] [ERROR] [10/28/2010 9:47:36 AM]: Upgrade object too new (build version = 12.0.0.6327, schema version = 3.1.6.0). Current server (build version = 12.0.0.6327, schema version = 3.0.10.0). [SPManager] [ERROR] [10/28/2010 9:47:36 AM]: CanUpgrade [SPConfigurationDatabase Name=SharePoint_Config-New Parent=SPDatabaseServiceInstance] failed. [SPManager] [ERROR] [10/28/2010 9:47:36 AM]: The specified SPConfigurationDatabase Name=SharePoint_Config-New Parent=SPDatabaseServiceInstance has been upgraded to a newer version of SharePoint. Please upgrade this SharePoint application server before attempting to access this object. Am I going to have to contact MS about this issue?? Cheers again ConradConrad Goodman MCITP SA / MCTS: WSS3.0 + MOSS2007

Anyone?Conrad Goodman MCITP SA / MCTS: WSS3.0 + MOSS2007

Have now logged a support ticket with microsoft and will post the resolution.Conrad Goodman MCITP SA / MCTS: WSS3.0 + MOSS2007

Any luck with this? I've just hit the same issue.

Yes, I would be curious as well as I am unable to reproduce the issue.... -Ivan Ivan Sanders My LinkedIn Profile, My Blog, @iasanders.

Guys, You aren't going to like the answer to this one. It appears my predecessor has hard edited various tables (specifically the dbo.Versions table) in the configuration database and the content databases. Those databases are now effectively scrap and Microsoft will not support them - only supported route forwards is to create a new configuration database (not a problem)... However as the versions tables of the content databases have been messed around with also, there is a missing table (at least one!). The missing table I have found was 'dbo.DatabaseInformation', and from my research this was introduced in the 'Infrastructure Update for Microsoft Office Servers'. This patch is installed on my farm, but the table is not in the content databases. Microsoft have effectively pulled the plug on supporting our environment until I fix or restore the databases from backup. Now it's not possible for me to restore them, as they have been in this state for a couple of years (I've restored backups and looked at the tables). The resolution I am attempting is to do site collection level backups from the content databases, and then restore those into new content databases. I can get this to work with a 100GB site collection, but most of my site collections are 200-600GBs (hideous I know) so I am now trying to do a similar thing with Microsoft DPM, hoping that it offers me a higher level of fidelity..However it causes further complication as you need a recovery farm with at least enough space as your largest DB, and you need to pre-create the sites with the relevant template etc. Hope this helps someone, I am really struggling with this stuff but I am 110% confident that the methods I am trying are the only ways forwards. Remember STSADM backups aren't really supported over 15GB. Cheers, ConradConrad Goodman MCITP SA / MCTS: WSS3.0 + MOSS2007

Guys, You aren't going to like the answer to this one. It appears my predecessor has hard edited various tables (specifically the dbo.Versions table) in the configuration database and the content databases. Those databases are now effectively scrap and Microsoft will not support them - only supported route forwards is to create a new configuration database (not a problem)... However as the versions tables of the content databases have been messed around with also, there is a missing table (at least one!). The missing table I have found was 'dbo.DatabaseInformation', and from my research this was introduced in the 'Infrastructure Update for Microsoft Office Servers'. This patch is installed on my farm, but the table is not in the content databases. Microsoft have effectively pulled the plug on supporting our environment until I fix or restore the databases from backup. Now it's not possible for me to restore them, as they have been in this state for a couple of years (I've restored backups and looked at the tables). The resolution I am attempting is to do site collection level backups from the content databases, and then restore those into new content databases. I can get this to work with a 100GB site collection, but most of my site collections are 200-600GBs (hideous I know) so I am now trying to do a similar thing with Microsoft DPM, hoping that it offers me a higher level of fidelity..However it causes further complication as you need a recovery farm with at least enough space as your largest DB, and you need to pre-create the sites with the relevant template etc. Hope this helps someone, I am really struggling with this stuff but I am 110% confident that the methods I am trying are the only ways forwards. Remember STSADM backups aren't really supported over 15GB. Cheers, ConradConrad Goodman MCITP SA / MCTS: WSS3.0 + MOSS2007

Guys, You aren't going to like the answer to this one. It appears my predecessor has hard edited various tables (specifically the dbo.Versions table) in the configuration database and the content databases. Those databases are now effectively scrap and Microsoft will not support them - only supported route forwards is to create a new configuration database (not a problem)... However as the versions tables of the content databases have been messed around with also, there is a missing table (at least one!). The missing table I have found was 'dbo.DatabaseInformation', and from my research this was introduced in the 'Infrastructure Update for Microsoft Office Servers'. This patch is installed on my farm, but the table is not in the content databases. Microsoft have effectively pulled the plug on supporting our environment until I fix or restore the databases from backup. Now it's not possible for me to restore them, as they have been in this state for a couple of years (I've restored backups and looked at the tables). The resolution I am attempting is to do site collection level backups from the content databases, and then restore those into new content databases. I can get this to work with a 100GB site collection, but most of my site collections are 200-600GBs (hideous I know) so I am now trying to do a similar thing with Microsoft DPM, hoping that it offers me a higher level of fidelity..However it causes further complication as you need a recovery farm with at least enough space as your largest DB, and you need to pre-create the sites with the relevant template etc. Hope this helps someone, I am really struggling with this stuff but I am 110% confident that the methods I am trying are the only ways forwards. Remember STSADM backups aren't really supported over 15GB. Cheers, ConradConrad Goodman MCITP SA / MCTS: WSS3.0 + MOSS2007