I recently worked on a MOSS 2007 project with a unique constraint: it required extensive customization without the use of actual code. Due to this architecture requirement, I found myself making heavy use of SharePoint Designer 2007 and calculated fields where I would usually write a custom feature.
Since I was spending so much time in SharePoint Designer, when the time came to back everything up, I instinctively used the built-in "Backup Web Site" feature (found under the Site -> Administration menu). Normally, I would have jumped to the command line and run "stsadm -o backup", but I figured there was no need to leave the robust tool I was already in.
Once the backup completed, I fired up my development virtual machine to verify. (If you’ve ever been burned by a faulty backup, you know how important it is to verify the archive!) In this second environment, I opened SharePoint Designer and ran the "Restore Web Site" feature (found under Site -> Administration). This restore tool came back with an unhelpful error message, and I didn’t see a log entry to check out.
I next decided to fall back to the tried-and-true "stsadm -o restore" command for answers. This command also failed with the error:
“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.4729335.0’ or later”
I remember thinking ‘Hmm, I know Microsoft has been making rapid progress on SharePoint, but I don’t think they’re up to version 1,178,817,357 yet…’ Thinking I was working with a bad backup, I repeated the process and reached the same conclusion.
Stymied, I started researching and found others with the same situation, but no posted solutions. When I came back to the problem, I immediately realized the issue as I noticed the file extension of my SharePoint Designer backup: it was a .CMP file (Content Migration Package), which is what the "stsadm -o export" command generates.
What SharePoint Designer calls a backup is what stsadm considers an export.
Realizing the inconsistency, I switched to "stsadm -o import" and things worked! Well mostly; the export reported a column conflict that had prevented the original SharePoint Designer restore from operating. Once that was corrected, I was able to pull the data from either mechanism ("restore" in SharePoint Designer, "import" in stsadm).
Hopefully, this will save some time for anybody who tries to reconcile a SharePoint designer backup with stsadm (a likely scenario when designers hand off to developers or administrators).
In hindsight, I should have immediately noticed the .CMP file as an export, but because backups have no default file type, I gave it no thought.
Curious about the difference between backups and exports? Check out this quick breakdown from Catch My Point.
