In the last couple of years I received several cases related to problems when using "stsadm -o restore" or "Restore-SPSite" commands.
The users received an error message similar to the following:
Your backup is from a different version of Windows SharePoint Services and cannot be restored to a server running the current version. The backup file should be restored to a server with version '1262884508.196508.17294360.0'
The version number in the error message varies but is always a very big number which is not at all a version number for SharePoint.
This error occurs whenever you are trying to use a file which is not a SharePoint backup with the restore command - e.g. a SQL backup or a SharePoint export file. SharePoint tries to read the version information from the file header of the file - and if the file is not a SharePoint backup file the data at the location where SharePoint expects to find the version information is usually something completly different.
In most cases the relevant files were either SQL backup files or created with STSADM -o export.
I've noticed that you've taken an interest in the forums recently, and as this is a fairly common question (across all versions of SharePoint), I think that this is a well timed blog entry.
I've been seeing this issue when trying to move a site from one farm to another. Both farms are at the same patch level.
Content deployment fails (I've followed your blog articles):
"Content deployment job 'Remote import job for job with sourceID = d5f5cedd-cc28-40b5-8dd9-c5f905f54e7b' failed.The exception thrown was 'System.IO.IOException' : 'The process cannot access the file 'Manifest.xml' because it is being used by another process.'
When I try to restore a backup taken using STSADM in the destination farm I get:
"Your backup is from a different version of Windows SharePoint Services and cannot be restored to a server running the current version. The backup file should be restored to a server with version '1178817357.0.25229151.0' or later."
I've tried Chris O'Brien's Content Deployment wizard tool to take data out of the host and bring into the new server. On trying to bring the data in I get:
"Error on import on new host: "System.IO.IOException: The process cannot access the file 'Manifest.xml' because it is being used by another process." shown in GUI" returned in the GUI.
In the log file I get:
"[11/2/2011 3:31:10 PM]: FatalError: The 'www.w3.org/.../XMLSchema:attribute& element is not supported in this context.
at System.Xml.Schema.XmlSchemaSet.InternalValidationCallback(Object sender, ValidationEventArgs e)
at System.Xml.Schema.XmlSchemaSet.ParseSchema(String targetNamespace, XmlReader reader)
at System.Xml.Schema.XmlSchemaSet.Add(String targetNamespace, String schemaUri)
at Microsoft.SharePoint.Deployment.SPImport.CreateXmlReader(FileStream fs, String schemaNamespace, String schemaFile)
at Microsoft.SharePoint.Deployment.SPImport.GetNextManifestFile(XmlReaderAndStream reader)
The Import Error clearly shows that the WSS patch level is different. Because different patch levels can have different Schema versions in the manifest.
Regarding the "in use" issue: sounds like your Virus scanner is badly interacting with the import.
Thanks Stefan. I'll check the virus scanner and will revisit installed versions to be 100%.
Have checked farms.
Host reports (STSADM preupgradecheck):
"This sharepoint software currently running on this farm is 184.108.40.20621"
Destination (STSADM preupgradecheck):
This sharepoint software currently running on this farm is 220.127.116.1121
There is no AV running on the server where I'm trying to move the site to yet (DEV site).
then I would suggest to open a support case to get this analyzed.
I *think* that there are a couple of factors influencing this issue, one of which you address here but another one that I think was introduced with the release of Service Pack 1 for SharePoint 2010. I hadn't considered the possibility you mention of trying to restore a backup with SharePoint's catastrophic restore tools that was not created with those same tools. That's a great point to keep in mind.
However, there's another issue raised by Service Pack 1 that I think is contributing to a lot of the issues people have been raising in the last few months when they try to restore a backup: backups created in a farm before SP1 was applied can not be restored after SP1 was applied. This is a bit of a change, because to the best of my knowledge it was possible to restore a backup from a older SharePoint build version into a farm running a newer SharePoint build version in both SharePoint 2007 and in SharePoint 2010 prior to SP1. I know that I've done such a thing in SharePoint 2007 w/o any issue, but I haven't gotten a chance to try it in 2010. Interestingly, the documentation I've found in TechNet for both the 2007 and 2010 releases state that this is not supported, but I know that at a minimum it was at least possible to do successfully.
But, now with SP1, you can't restore a pre-SP1 backup into a farm running SP1. This is a known issue to the point where there's actually an article in TechNet about it: technet.microsoft.com/.../hh344831.aspx. As the article states, SP1 introduced several changes various SharePoint database schemas to where they don't line up well enough to allow for older backups to be restored. In about 90% of the cases I've seen, this is the issue that causes the error you're mentioning, rather than trying to use incorrect backup files.
Chris Howell, I would suggest trying to run the SharePoint Products Configuration Wizard in your original farm and your target farm to see if there is a database somewhere in them that hasn't had all the proper updates applied, this could be causing the version mismatch. If running it via the GUI doesn't work, I would try calling it from the command line with the ForceUpgrade switch to see if that works: psconfig.exe -cmd -upgrade b2b -wait –force. I don't know if that's going to resolve it for you or not, but its one way you can try resolving your version conflicts and cross one possible cause off your list.
Great post.. But is there some work around if we dont have the same version on different servers ??
Useful post Stefan,
Actually, I faced the same problem with our development environment, but I’ve done workaround to get the content database using this way : www.megren.net/.../Post.aspx