Brainlitter » Resolution to strange SharePoint SQL Database Restore Problem

Resolution to strange SharePoint SQL Database Restore Problem

The Requirement

A customer had quite the mess of a SharePoint farm. Efforts are being made to clean it up … but in the meantime, they required a backup of a SharePoint Content Database (from 5 days ago) to be restored into a new (temporary) Web Application to retrieve some old data. Typically, this would be a simple request.

 

The Issues

The problem was, when it came time to restore, we experienced the following problems (differing, depending on minor changes to the approach):

  1. Content Database would not attach at all (using this syntax: stsadm.exe -o addcontentdb -url http://servername:port -databasename content_database_name -databaseserver SQL_Server_Name). This would return the following Error… The specified SPContentDatabase Name=content_database_name Parent=SPDatabaseServiceInstance has been upgraded to a newer version of SharePoint. Please upgrade this SharePoint application server before attempting to access this object.

    Or…

  2. The Content Database would attach (using above syntax) but Central Administration would indicate that the Content Database contained “0” (zero) sites and if you attempted to go to the Web Application, you would get a 404

 

What We Tried First (Validation)

  1. First, as it seemed pretty clear there were version issues, I verified that the Farm was at the expected build number (MOSS/WSS SP1 by the way) – and it was (6219).
    1. How: In Central Admin, Operations, Servers in Farm
  2. Second, I verified each WFE’s version
    1. Find/compare Owssvr.dll (in 12 hive isapi directory)
    2. In the Registry – “HKEY_LOCAL_MACHINESOFTWAREMicrosoftShared ToolsWeb Server Extensions12.0”, verify versions are the same
  3. Third, I verified that the restored Content Database was at the same version (well, or so it reported…)
    1. How: In SQL, perform the following Query against the database

      SELECT [VersionId]
            ,[Version]
            ,[Id]
            ,[UserName]
            ,[TimeStamp]
            ,[FinalizeTimeStamp]
            ,[Mode]
            ,[ModeStack]
            ,[Updates]
            ,[Notes]
        FROM [WSS_Content].[dbo].[Versions]

      Or…

      select * from versions order by timestamp desc

  4. Groupboard Workspace was once installed in the environment as well (and the Farm had recently been rebuilt in haste), so we attempted to put that back temporarily to see if that had any effect

 

The Solution

So, it was pretty clear WSS/MOSS SP1 was applied everywhere (but the *history* behind the Farm and some knee jerk reactions does leave some question as to the overall stability and consistency of the environment). Thus, we took the following steps (remember, the requirement was to get some data from an old site backup – next steps of course will be to bring the farm to SP2 to be more recent/compliant and supportable for the long haul).

 

  1. Built a ‘beater farm’ (a playpen, separate from Dev and Production, that we were comfortable with manipulating/patching as necessary) with SP1 installed and GroupBoard Workspace (though unclear still whether that mattered in the end … but I don’t care on a Saturday when I should be getting ready to watch the Leafs vs. Penguins game)
  2. Restored the SQL Database from backup one more time
  3. Created a new web application
  4. Removed the DB created by the new web application
  5. Attached the SQL Database to the new web application (again, see syntax above)
    1. Still “0” sites if restored into a web application with no Site Collection pre-created previously in new Web Application
    2. Still get “The specified SPContentDatabase Name=FLAGCONTENTDB1 Parent=SPDatabaseServiceInstance has been upgraded to a newer version of SharePoint. Please upgrade this SharePoint application server before attempting to access this object.” If we restored into it, without pre-creating a site collection in the placeholder web application
  6. Applied SP2 to the Beater Farm … and we have success… We can mount the site collections and retrieve the necessary, archived data – the customer’s requirement is met

 

 

Yep, after all that, despite the Database indicating it was created with SP1, it would not restore into an SP1 environment. An upgrade to SP2 however was sufficient to bring the content back online so the data could be retrieved.

 

 

Hope this helps someone, somewhere.

 

 

References