Alright, today’s blog post is going to be a bit infrastructure related. More specifically, I’d like to document an issue we encountered recently trying to do a restore from a production server to one of our development boxes. We do this often to keep our development data fresh and in sync with production, otherwise it becomes difficult to do any sort of real testing with numbers. Usually, this is a pretty standard procedure for us:
- Within Central Administration, under Application Management, we navigate to Content databases
- Making sure to select the Web Application we plan to restore to, we click on the WSS_Content link (or whatever happens to be the name of your db)
- Within the Manage Content Database Settings page, change the Database status drop down from Ready to Offline
- From here I stop the IIS Web Site, restart SQL Server and kick off my restore
- Once the restore is complete, I head back into my Manage Content Database Settings page and switch the Database status back to Ready
Now usually this works without issue. But recently, while attempting to do this on a machine we hadn’t worked with on a few weeks, we were encountering all sorts of errors trying to navigate to our site collection. Specifically, we were seeing the following error in the Operations logs:
The specified SPContentDatabase Name=WSS_Content Parent=SPDatabaseServiceInstance Name=Microsoft##SSEE has been upgraded to a newer version of SharePoint. Please upgrade this SharePoint application server before attempting to access this object.
Based on this error, my first thought was to check the dbo.Versions table to see if perhaps we had a conflict in versions as this error would suggest. Unfortunately, trying to read from the dbo.Versions table resulted in this pretty error:
Msg 33002, Level 16, State 1, Line 1
Access to table dbo.Versions is blocked because the signature is not valid.
So now we’re having fun at this point. I can’t read from the dbo.Versions table, so I don’t really know what the patch level of this particular server is. After checking production, I know that my patch level is 188.8.131.5204. In order to cross check what this means, you should have this link handy from the SharePointDevWiki.
Based on what I was reading there, my production server had the: MOSS 2007 or WSS 3.0 April 2009 Cumulative update. I know I probably could have done the research and checked file versions, but why should I have to do that when all I really needed to do was read from dbo.Versions? After a bit of troubleshooting, I realized it would make the most sense to simply spin up a new Web Application and fresh content db on my development box and read ITS dbo.Versions table. Turns out that original error was right on the money, my development box was one version behind: 184.108.40.20621.
Once I upgraded to the missing cumulative update and tried my restore process again, everything was back to normal! I hope that helps someone understand what the dbo.Versions table is all about, and what you can do to get past these errors.