Many MOSS installations, particularly those that have grown over time or have been upgraded from SharePoint 2003, will have their mysite collection within another application, typically the intranet/portal. As the portal has matured, it becomes necessary to move the personal sites into their own application, within their own content database(s). We faced this situation ourselves, so here's how we did it:
First of all, what we had to start with was a structure left over from SharePoint 2003, as follows:
1 content database: SharePoint1_site
1 application: sharepoint
The structure we want to achieve is:
New content database for the mysites: WSS_Content_InternalMySites (using the new naming convention)
Mysites hosted on their own application, in a new site collection:
With the portal remaining as is, all existing mysites migrated to the new application/database, and any new mysites created under the new application in the new database.
The steps we followed were:
- Ensure we have a full farm backup in Data Protection Manager
- Use stsadm enumsites with an xml out file to get a list of the sites within the existing database. stsadm -o enumsites -url
http://sharepoint -databasename sharepoint1_site > Mysites.xml
- Edit this xml file so that only the personal sites are listed, save the file
- Add a new content database called "WSS_Content_InternalMysites" to the existing
- Run stsadm mergecontentdbs, injecting the list of sites and specifying the source and destination databases:
stsadm –o mergecontentdbs –url http://sharepoint –sourcedatabasename sharepoint1_SITE -destinationdatabasename WSS_Content_InternalMySites –operation 3 –filename MySites.xml
- At this point, we have the sites split between the two databases - this is a useful operation to know as it is, and can help you arrange site collections that have "outgrown" one database into a new one (100GB is a good size for each content DB)
- Create a new application for the mysites - this will create a new content DB. It doesn't matter what this is called, as it will be removed soon. Reset IIS.
- Remove the WSS_Content_InternalMysites from the list of content DBs in the original application, and add it to the list in the mysites application. Remove the empty content database that was created as part of the application creation process.
- Create a mysite site collection in the new application, so that new mysites are created using the correct template
- To ensure all the original paths work in the migrated sites, we created a new managed path with explicit inclusion for "mysite". This may vary for other migrations, and may not be necessary at all.
- Update the SSP to point at the new application. One more IISReset for luck.
- Log in to the "system" account mysite - this will prompt you to update the default mysite location.
- Login as one of the users with a migrated mysite - you should see the original content. Also try a new user to make sure new mysites are created.
- Refresh DPM so that it picks up the new database and backs it up as part of the farm.
Couple of caveats:
- Don't use this for site collections with a size over 10GB (the enumsites operation gives you the size of each size collection within the database). You can use batch site manager to move site collections between 10 and 15GB, as this uses backup/restore instead of mergecontentdbs. For mysites, these limitations shouldn't apply, but if your are using this method for other site collections, they may well do.
- Always do this out of hours, when database and WFE resources are free.
- You may want to lock your site collections before the move, and quiesce the farm.
- Don't cancel the operation - you'll corrupt both databases (but as you've made sure you've got a valid backup in step 1, this won't matter, right? ;) )