One of my most popular SharePoint 2007 blog posts is about using the STSADM operation mergecontentdbs to move site collections from one content database to another. It showed up in Service Pack 1 of SharePoint 2007 and made the process of shuffling site collections around much easier. Through service packs and cumulative updates it got stronger over the years. When SharePoint 2010 hit the streets our options got even better. Not only do we get mergecontentdb's direct replacement, Move-SPSite, but we also get a way to remove some of the need for its use in the first place. In SharePoint 2007 there was no way out of the box to create a new site collection in a specific content database that already existed. The closest we had was the createsiteinnewdb STSADM operation that would create a new content database for our new site collection. To create a new site collection in a specific content database we had to use tricks like put the content database in the offline mode, or play with its maximum site number. These techniques worked okay if you had a small SharePoint 2007 shop, but once a couple new administrators got into the mix things got ugly. Fortunately for us, SharePoint 2010 is here to save us from all of that. I was talking to my buddy Anders Rask about this last week. He was doing this for a SharePoint 2007 environment and it reminded me how much better the story is in SharePoint 2010. Anders' pain turned into a tasty new blog post for you guys. Everyone thank Anders.
We no longer need mergecontentdbs, we now have the Move-SPSite PowerShell cmdlet. It's a little easier to use than its STSADM counterpart, and because it's in PowerShell, it's a lot more flexible. It can also dance better and it cooks a mean omelet. At its most simple, you can use it like this:
Move-SPSite http://sharepoint/sites/moveme -DestinationDatabase WSS_Content2
For this to work, the content database that the moveme site collection is currently in must be on the same SQL server as WSS_Content2 and moveme but be in the same web application as the WSS_Content2 database. Mergecontentdbs has those same limitations though, so we're used to them.
Instead of having to cobble together XML files to do multiple site collections at a time, like we did with mergecontentdbs, now we can just loop through a collection of site collection objects and only move only the ones that meet our specific criteria. For instance, to move all the site collections where contoso\todd is the owner, to the content database WSS_Content2 we would use this line:
Get-SPSiteAdministration | Where-Object { $_.OwnerLoginName -eq "contoso\todd" } | Move-SPSite -DestinationDatabase WSS_Content2
The first cmdlet we use is Get-SPSiteAdministration. This is like Get-SPSite, gets us a collection of the site collections in our farm. Unlike Get-SPSite, Get-SPSiteAdministration includes site collections that the user running the command does not have access to. We can use any site collection property as our filter, including name, template, content database, anything we would like. Our imagination is the limit.
Like I mentioned earlier, part of the reason we needed mergecontentdbs was because there was no good way to control which existing content database a new site collection went into in SharePoint 2007. We had a few workarounds, but like most workarounds they had some downsides. For instance, if we set a content database to Stopped or Offline a new site collection would not go there. First, you had to somehow decipher the cryptic meanings of "offline" and "stopped. Not even the Rosetta Stone is any help there. Setting a database in that mode had some collateral damage, like profile sync no longer worked. Our second technique was to set every content database's maximum sites setting to its current number of sites. That way SharePoint had to put the new site collection someplace else. The problem with that is that when you're culling out old site collections your maximum is no longer the current number of site collections. After each site collection deletion you have to go through your databases and adjust the maximum to the new current number of sites. That is kind of a pain, and tough to remember to do. Both of these techniques really start to fail once you have more than one person managing your farm. Again, SharePoint 2010 and its sidekick PowerShell come to the rescue.
In SharePoint 2010 when we create a new site collection with New-SPSite we have an optional -ContentDatabase parameter we can define. If we want that new site collection to go into a specific content database, we just tell New-SPSite and it puts it there for us. How considerate. However, there was one tradeoff. There is no PowerShell equivalent of the old Createsiteinnewdb STSADM operation. The content database has to exist for it to work with New-SPSite. That's okay though; creating new content databases with New-SPContentDatabase is fun, so we don't mind doing it anyway. Just create the database first and then drop your new site collection into it.
I hope this blog post has helped explain some of the new functionality in SharePoint 2010 and will allow you to put our old pal mergecontentdbs out to pasture for good.
tk