I recently had to copy a locked SharePoint site collection from one farm to another farm. I soon realized this wasn’t such a great idea especially if the farms aren’t in the same AD domain. Here is a quick recap of what I noticed after a few more investigatory steps.
Eager readers will eagerly jump to the final conclusion.
Copying though stsadm backup/restore
Let’s try copying this site collection with the stsadm backup and restore commands. Both farms are MOSS RTM farms.
The backup worked smoothly. The restore is a total disaster (“Additions to this Web site have been blocked. Please contact the administrator to resolve this problem.”) :
The weirder part is that the collection is visible in the central administration but it seems totally messed up. No way to delete it from the Central Adminsitration. The stsadm deletesite command returns the “Additions to this Web site have been blocked. Please contact the administrator to resolve this problem.” error.
Conclusion : Not a good idea ! Might actually works using the trick I finally used, see below.
Copying using a SQL Server backup
Seemed like today would be another day battling with SharePoint. But I wasn't short on idea. Indeed My locked site collection was alone in its content DB, therefore I was able to use a backup to restore the collection on my target farm.
The restore wentsmoothly. I was starting to believe it was actually going to be easy!
And then my frail hopes were cruelly shattered by the terrible SharePoint truth when I opened up the Central Administration to change the collection administrator.
The first obvious step is to select the site collection but when selecting the site collection in the “Select Site Collection” popup, none of the collection details would appear on the right.
Huh ? I tried validating the popup anyway and was presented with this screen:
It seemed just as if I had selected nothing, yet the adress bar contained the id of the content database :
Trying to unlock this site collection would produce kind of the same result.
I then realized that the farm administrator had no right on the collection. He indeed had no permissions on the collection when it was backuped. Lucky me, the farms were part of the same domain, therefore I tried a quick and dirty fix, I added the original farm administrator to the target farm administrator group and logged in the Central Adminsitration with this administrator.
It was a relief to be able to see the details of the collection. Thou shan’t prevail over me SharePoint !
But once again, I underestimated my adversary which quickly retaliated with a now too common “Additions to this Web site have been blocked” when I tried changing the collection administrator.
But victory was mine at long last when I unlocked the collection while logged in with the original farm administrator account on the target farm. After this step I was able to change the collection administrator to the target farm administrator as I intended from the beginning.
Conclusion : It works, but both farms have to be in the same AD domain
Final Conclusion
If possible I would advise you to unlock the site collection before proceeding with the copy. If it isn’t possible, I hope both of your farms are part of the same AD domain, otherwise good luck! Please keep me posted if the powers that be are you on your side.
By the way, for those of you thinking that I should have tried the stsadm export command, one simply can’t export a locked site collection this way.
4 comments:
Verry good blog! I have the exact same problem. If I understand you right you should not use the lock command before making a backup if you use it on a completely different environment, is that right?
Hi Marco,
That's right, it's possible on a different server as long as it's part of the same domain/forest or trust the original domain.
Regards,
Joe
Hi Joe,
Thank you for your answer. Don't you think that there is a big chance that the back-up will become corrupt if you don't use the site lock? Is there a alternative way to make a non corrupt back-up. Do you have any experience with this?
Regards,
Marco
Marco,
If you running WSS or MOSS SP2 no trouble as no content can be added/modified when backing up.
With older versions, I have never had any trouble with backup done outside of business hours. If you are running a 24h/24h instance (clients from all over the world), you might want to set your content to read-only but then you might encounter the problem described in this post. I guess the solution is to restore on a server in the same domain.
Joe
Post a Comment