views:

307

answers:

1

There seems to be no end to conflicting information out there regarding whether or not it is necessary to use "setsitelock" when backing up a site collection for deployment to another farm, if both farms have SP2 installed.

According to Bob Fox's blog (comments disabled), it is no longer necessary: http://bobfox.securespsite.com/foxblog/Lists/Posts/Post.aspx?ID=121

However, according to the STSADM blog, this luxury only comes with the April CU: http://stsadm.blogspot.com/2009/05/backuprestore-now-supported-between.html

And from what I can see, the April CU is indeed NOT part of MOSS SP2: http://www.microsoft.com/downloads/details.aspx?FamilyId=B7816D90-5FC6-4347-89B0-A80DEB27A082&displaylang=en

Has anyone got a definitive answer on this? Thanks :-)

+3  A: 

IrishChieftain,

I agree that things get pretty darn confusing when trying to figure out how things change between service packs, cumulative updates, "uber packages," server packages ... UGH! Hopefully, this link clears things up. Read the "Important" block, as it specifically addresses your concern:

http://technet.microsoft.com/en-us/library/cc287893.aspx

The articles you cited above (Bob Fox's and Gary Lapointe's) actually deal with two different things. Bob's article talks about the automatic locking behavior that is also described in the TechNet article I cited, and it is correct.

Gary's article (the 2nd link) - which references an article from Stefan Gossner (an exceptionally well-versed MS escalation engineer, particularly in the MOSS publishing/WCM space) - doesn't describe the April CU as fixing locking behavior, but rather as providing absolute reference/link fixups for publishing sites.

Since the release of MOSS, publishing sites have been a pain in the butt from a migration, backup, and export perspective. Site templates (.STP) couldn't properly be exported out of publishing sites, and other problems existed because layout pages maintained absolute references to their hosting servers. With the April CU, workarounds for this problem should no longer be necessary.

So ... if you've got SP2 on your source farm, you should be in the clear and leveraging auto site locking on backup.

I hope this helps!

Sean McDonough
Perfect answer Sean, thanks so much,Anthony :-)
IrishChieftain
So, I take it that without the April CU, there could by layout problems if I try to restore a site collection to another farm? What bout moving the content DB to another farm (what I really want to be able to do)?Already got the book by you and John, and it was really helpful :-)
IrishChieftain
You've summed it up well, Anthony: there *could* be a problem. It all comes down to whether or not absolute references are being stored. In all honesty, I don't know how common a problem this is. To address your specific question, though: 99% of my work in MOSS is with publishing sites. I've backed-up from one farm and used the backup to restore to other farms. I've also detached content databases from one farm and reattached them in other farms. I haven't (yet) run into problems ... but again, whether or not you'll have a problem is going to depend on your sites -- not the process.
Sean McDonough
Do you have a VM you can test in? It's really pretty low risk to take the content DB offline, make a copy, and reattach the copy in another farm to see if you'll have issues. Provided it's not huge, you'd only be setting yourself back 15 or 20 minutes -- not a bad investment of time. Oh yeah ... and thanks for buying our DR book -- we're glad you found it helpful! Feedback like yours makes having written it worth the effort :-)
Sean McDonough
Yes, I had already created a restore of our Publishing site to a test VM and it seems to be working fine although we are not using a wide array of layouts so I can't be sure. Is there an easy way to check for layout references hard-coded to the source server URL?
IrishChieftain
I was looking at the code within Stefan Gossner's FixPageLayout tool (http://code.msdn.microsoft.com/FixPageLayout/Release/ProjectReleases.aspx?ReleaseId=1709), and as it runs it will alert you to layout pages that have an absolute URL that points to the wrong server. The console output that is generated when running it against your site in the test VM should give you the list of layout pages requiring fix-up. Of course, by itself the tool will also clean everything up for you following migration -- nice "safety net" :-)
Sean McDonough
Thanks for the info Sean :-)
IrishChieftain