Move SiteCollections between WebApplications

edit: Please read this blog post before using 'mergecontentdb' data corruption may occur

On multiple occasions as a SharePoint administrator I have needed to move a Site Collection from one Content Database to another one. In the past this process was very painful and very manual. In this blog post I will show you how to move Site Collections between Content Databases with a single STSADM command using the "mergedbs" operation that was introduced in KB934525.

Why would I need to move a Site Collection to a different Content DB? This comes up for a variety of reasons. For instance, because of restore times, I like to keep my databases under a certain size. While I try to work with my Site Collections owners to plan accordingly sometimes they grow larger than we had imagined. When this happens I need to shuffle Site Collections around to keep my databases in harmony. There are other times when I would do it if it were more convenient. If Site Collections are not growing as expected, I may want to consolidate several into a smaller Content DB. I may also want to move less active Site Collections to Content DBs on slower discs, or move Site Collections to Content DBs that reflect geographic regions. Whatever the reason, in the past to move a Site Collection you had to go through the following steps manually;

1. Lock the Site Collection
2. Back the Site Collection up
3. Delete the Site Collection
4. Set all your Content Databases' maximum allowed sites to the number of current sites.
5. Set the Content Database you want the Site Collection to go into to allow one more Site Collection.
6. Restore the Site Collection
7. Unlock the Site Collection
8. Adjust your Content Database maximums to allow new sites to be created.

All of these steps could be done with STSADM so you could build scripts and move through the process quickly. In one of the recent security patches (KB934525) for WSS and MOSS Microsoft slipped in a new STSADM operation, mergecontentdbs. I assume this operation was added with the intention of merging Content DBs, but it can also be used to split them. This blog post will walk you through both uses. Let's start with the configuration below:

You can see in this screenshot that I have three Site Collections in two Content DBs; WSSContent and WSSContent2. Let's move http://barcelona/sites/stsadm from WSS_Content to WSS_Content2. If you get the help for the mergecontentdbs operation it looks like this:

We want to use operation 3, Read from file. STSADM has given us a clue about the file needed, it is generated from stsadm –o enumsites. I'll go ahead and run that and pipe it to a file like this:

This will produce a file, mysites.xml, that contains my site collections. To move http://barcelona/sites/stsadm we'll remove all of the other Site Collections except for that one from mysites.xml and save it. You don't need to worry about changing the Site Count at the top, or any of the other Site Collection information in the file, STSADM only grabs the URLs out. I only have two Content Databases so the decision of which database to move the Site Collection to is easy. What if I had many Content Databases? You can use the first operation, Analyze, to get an idea of how your Content Databases are laid out. Let's see how that looks:

You can see here where I got the idea to use the filename mysites.xml. The thing I love best about this screen is that you can just cut and paste the final command into your Command Prompt if you'd like. I think Microsoft did a great job with the usage on this command. One thing to note is that the –url parameter is NOT the URL of the Site Collection you want to move, it's the URL of the Web Application that the Site Collection is in. Since we've already created our file and edited it, let's go ahead and run the command.

That's all there is to it. After an iisreset we see that the Site Collection http://barcelona/sites/stsadm is now in WSS_Content2. You can confirm it by looking in Central Administration > Applications > Content Databases before and after you run the command.

I have one final thing to show you, what I imagine is the intended usage of mergecontentdbs, merging two Content Databases. If we use the second operation STSADM will simply move all the Site Collections from the Source database to the Destination database. Let's move all of the sites in WSS_Content2 back into WSS_Content.

I think that picture pretty well sums it all up. Now all the Site Collections in the http://barcelona Web Application are in WSS_Content, right where we want them. I think Microsoft did a pretty good job with this addition to STSADM. Enjoy it.

I'd like to give a special shout out to Joel Oleson for telling me to look for this little gem.

tk

Move Site between site collections

Posted by milap shah

How To: Move a single Site between Site Collections

Hey,

I'm hearing a lot of this question in many variations and I figured it's time to solve it once and for all. The problem is well known: trying to move a WSS Site between 2 different places (such as Site Collections) is still not something we're doing with a click of a button. There is no real and easy of doing so and I've heard about many "nasty" solutions (such as Backup/Restore for entire Site Collection, Copy-Pasting everything with the Explorer View and many other messy evils).

It looks like multiple teams in Microsoft have been tasked with this issue since we actually got 3 different ways to solve it:

• SharePoint Designer Backup/Restore - Definitely the easiest way to move sites around but only WHEN IT WORKS (since that's not a very consistent feature in SPD). To use this method, simply go to Menu --> Site --> Administration --> Backup Web Site and enter the URL of the WSS site you want to move. You can also include/exclude other subsites in the archive you're creating. Restoring it to the new Site Collection is done with the Restore Web Site feature in SPD. Again, remember this is not too consistent so always try to restore before deleting an original site (Even when you get the "Backup Operation was completed successfully" message!). 
  
• Stsadm.exe export/import - The stsadm.exe admin utility is not a new tool but in the 2007 it has many improvements. Now, we can use stsadm as a way to import and export single sites. By the way, this is actually how Share Point Designer creates the archive in the mentioned SPD method. Don't get confused with the backup/restore operations in stsadm.exe - those operations were already available in 2003 but they are used for entire Site Collections rather than a single site (and in our case it's a major overkill). Sounds great huh? Well, just like the SharePoint Designer way, it could easily become a MAJOR NIGHTMARE when it's not working so let me give you some tips. I hope this will reduce the amount of time spent CURSING THE HELL of our beloved stsadm's command line window and the its log file.

1. The default cabsize value is 25 Mb which is VERY lame for big sites! Always define ur own cabsize (up to 1 GB...)
   
2. It is highly recommended to add the “-haltonwarning” or “-haltonfatalerror” parameters. You'll be able to see a list of possible problems before proceeding with the creating on the archive.
   
3. If still encounter failures and you don't understand WTF that could be, You might want to try the –nofilecompression switch. Somehow, exports tend to fail in much bigger numbers when you try to compress them.

And to sum it all up, here's the complete command with all of the available switches for exporting/importing with stsadm.exe:

stsadm -o export -url <URL to be exported> -filename <export file name> [-overwrite] [-includeusersecurity] [-haltonwarning] [-haltonfatalerror] [-nologfile] [-versions <1-4> 1= Last major version for files and list items (default), 2= The current version, either the last major or the last minor, 3= Last major and last minor version for files and list items, 4= All versions for files and list items] [-cabsize <integer from 1-1024 megabytes> (default: 25)] [-nofilecompression] [-quiet]

stsadm -o import -url <URL to import to> -filename <import file name> [-includeusersecurity] [-haltonwarning] [-haltonfatalerror] [-nologfile] [-updateversions <1-3> 1= Add new versions to the current file (default), 2= Overwrite the file and all its versions (delete then insert),3= Ignore the file if it exists on the destination] [-nofilecompression] [-quiet]

• Content Deplyoment - Ok, now we're really talking! Let the real fun begin! This is probably the coolest and by far the most elegant way for synchronizing content between Site Collections. Although this is for a Site Collection level - it's a great way to make a lasting connection and keep moving new content between environments. Before using this method, you need to be familiar with two core conceptual objects: Paths and Jobs. A Path is set of definitions that represents a connection between the source environment and the destination environment. The path contains information about which source web application and site collection you are deploying, authentication information for the destination environment, and the web application and site collection on the destination MOSS. However, a path by itself doesn’t actually deploy any content - it's only a set of definitions. In order to sync the environment, you must create a Job. Each job is associated with a path, and determines exactly which sites in the source site collection will be deployed and on what schedule.

Now the really cool thing about this method: It uses the same logic and internal audit/log files as the Index jobs. That means that you can define a job that only deploys the changes since the last successful deployment and this could for a single item/document level. Great for saving bandwidth and time. Furthermore, if there are no changes since the previous job, the deployment will complete without redoing any unnecessary work. Of course, full deployments every time can be configured if that’s what you really want but this is not necessary in most cases.

Awesome hug? Although this is for Site Collection level, I think it addresses the main scenario that is main reason for wanting to move a list or a whole site between places: Replication between the Testing environment to the real Production environment. Using this method, you can define it once and deploy testing versions whenever you think you're done playing and it's time to publish your changes. You can find the Content Deployment management interface under the SharePoint Central Administration site. One aspect of content deployment that you should be aware of is that it will only deploy content, not any dependent assemblies/controls/webparts, etc.  Administrator is responsible for moving the assemblies for controls and webparts to the destination farm.

In conclusion - We're dealing here with 2 types of scenarios: If we're talking about moving an entire site ONCE between Site Collections - the SPD and stsadm.exe ways are preferred and you should just use them. If you're talking about synchronization between two environments and it's something that should happen every once in a while - we'll need that lasting connection that is provided through Content Deplyoment.

Subscribe to: Posts (Atom)