As I discussed in an earlier article backup/restore between farms for publishing sites was unsupported due to the fact that MOSS often stores absolute URLs to the Page Layout in the properties of a Publishing Page. Workarounds had to be used to adjust the incorrect URL after a restore to ensure that no exceptions occurred.
The good news is: due to the large number of customers requesting this feature Microsoft has decided to modify SharePoint in a way that it is now able to properly handle this situation!
Starting with the April Cumulative Update SharePoint now officially supports backup/restore operations for publishing sites between different farms!
Please ensure to have SP2 installed before installing the April CU as this is the only way to guarantee that all recent changes to SharePoint are available on your farm.
Permalink
PingBack from http://blogs.technet.com/stefan_gossner/archive/2008/03/12/common-error-situation-with-when-using-backup-restore-to-transfer-a-database-to-a-new-farm-on-moss-2007.aspx
Permalink
Voorheen was het niet mogelijk Sharepoint sites die de publishing features gebruiken te restoren op een
Permalink
Voorheen was het niet mogelijk Sharepoint sites die de publishing features gebruiken te restoren op een
Permalink
Great news!!
Does that sites that had the issue previously? Or only prevent the issue from happening moving forward?
-John
Permalink
Hi John,
I’m not completely sure. What I can see is that there is a code change in the DB attach code.
So I would suggest to detach and reattach the content DB. Then you should be on the save side.
Cheers,
Stefan
Permalink
Hi Stefan,
Great news, thank you for the info.
Do you know if the fix change the manner than Sharepoint store the Publishing page URL (use relative URL rather than absolute)? Or is a implementation of the Workarround in the STSAdm backup/restore command?
Thanks
Éric
Permalink
Hi Eric,
this works also for SQL level backup/restore with DB attach. So it is not an STSADM only fix. I did not analyze all the changes in detail (there are quite a lot for this fix) so I’m not sure if this is a one time fix during STSADM restore and/or DB attach or if it also affects ongoing operation later.
Cheers,
Stefan
Permalink
Please update your bloglinks. Guess you’re too busy dealing with all the MOSS updates and sp’s 😉 cheers
Permalink
Hi Ed,
thanks for the hint! Added a couple more blogs to the list.
Cheers,
Stefan
Permalink
Could backup/restore be a good approach for content deployment when you make sure that in your edit farm all "static" content is managed in a separate site collection? Dynamic data should be managed in a different site collection (in a different content database) on the production farm. If you would deploy content this way you can make complex changes to content types and site instances through code and deploy them in a breeze. This scenario would also support rollback by just attaching the previous DB. Really interested in your thoughts on this.
Permalink
Hi – I have a question: I am trying to see if I can setup a test environment that mimics our production MOSS+Project Server environment. As of now, I will have to use a different domain to setup the test environment. The number of servers in both environments will be same. Does the April CU need to be applied to the production env first, then to the test, and finally then can I use the backup/restore (from central admin) to restore to the test env? Or, it is better to use stsadm?
Any help is appreciated!
Permalink
Best is to use SQL backup/restore.
Permalink
We've recently found that we have this situation in a site collection created before the application of SP2 and the cummulative update. Is the use of the workaround tool supported by Microsoft, or a "use at your own risk" thing?
Permalink
Hi Stormbringer,
not sure which workaround tool you mean. But if you backup/restore the site after SP2 + April 2009 CU has been installed the site will be fixed.
Cheers,
Stefan