Using SMIGRATE to Backup, Restore and Migrate Team Sites in SharePoint Products and Technologies 2003

Transcription

1 Using SMIGRATE to Backup, Restore and Migrate Team Sites in SharePoint Products and Technologies 2003 Introduction In the last paper, I looked at using the STSADM command to backup and restore either an embedded or stand alone site collection. We saw how we could use STSADM to restore the site collection to a different URL path (and use this facility to affect an item level restore of a document, document library or list), so if we can copy a site collection to a different location, does this mean we can use the command to migrate them? Unfortunately, STSADM has the following limitations that really prevent us from using the command in this way: STSADM works with the site collection only. It cannot be used to backup or restore an individual site within a site collection. STSADM will only restore a site collection to a different URL path in the same portal. Therefore we are unable to use the command to copy site collections either between portals or between portal and WSS. Scenarios It is clear that the restrictions of STSADM are going to prevent us from effectively using the command in order to migrating sites and site collections and so we must look towards SMIGRATE. In the following sections we will look at using the SMIGRATE command to migrate sites in the following scenarios: Re-design of the site collection to move a sub site to a top level site or move a site from one site collection to another. Migration of a stand alone site collection into an embedded site collection. Migration of a site collection from one portal to another portal. Craig Carpenter Page 1 of 8

2 Craig Carpenter Page 2 of 8

3 Using the SMIGRATE Command SMIGRATE can be found in the bin folder of the 60 hive on Servers with Windows SharePoint Services installed. The full path of which is as follows: C:\program files\common files\microsoft shared\web server extensions\60\bin\ SMIGRATE has the following switches: -f Backup file name with the extension.fwp. SMIGRATE defaults to backup mode. -e Exclude sub sites from backup. -r Restore mode. -w URL to backup from or restore to. -x Exclude security from restore. Used when migrating from STS to WSS only. -y Confirm that you wish to over write an existing backup file. -u Specify Administrator username. -pw Specify Administrator password, or set to * to prompt user. A typical backup command would look something like: Smigrate w -f c:\backups\site1bak.fwp Whilst a typical restore command looks like: Smigrate r w -f c:\backups\site1bak.fwp In order to perform a restore with SMIGRATE, we must first prepare the target URL. Unlike STSADM which requires that the target URL is unused, SMIGRATE requires that a site exists in the target URL, but with no site template assigned to it. To achieve this, go through the normal site creation screens, and at the template selection screen, simply close the web browser without selecting a template. Craig Carpenter Page 3 of 8

4 Scenario One Site Collection Hierarchy Re-Design. This is a common requirement and certainly one that I have seen around the news groups a number of times. The depth of an existing site collection is deemed to be too great and so we are required to move all sub sites up one level. Or, we need to delete a high level site in a site collection that has existing sub sites underneath, and we need to retain those sub sites. In this example, we are going to start with an embedded site collection consisting of two sites, departments and marketing. In this example it has been decided that the departmental site structure is too deep and that the department top level site is no longer required. All departmental sites are required to be moved up one level and become top level sites in their own site collections. We are going to perform the following four steps: Use SMIGRATE to backup marketing site. Create new URL for marketing site by creating site but not applying template. Use SMIGRATE to restore marketing site to the new URL. Delete existing department site collection. Craig Carpenter Page 4 of 8

5 In order to back up the marketing site, we will issue the following command: Smigrate w -f mktbk.fwp This will make a backup of just the marketing site to the file mktbk.fwp which will be saved into the current folder. The next step is to prepare the restore URL path. To do this we need to create a site in that URL path without applying a template to it. We can do this with the following steps: From the Portal home page, click the Sites link on the top navigation bar. On the Site Directory page, click the Create Site link under Actions. Enter the site details, in this case: o Title: Marketing o Description: New Marketing Site o URL: /sites/marketing Click Create. On the Add Link to Site page, select the locations you want the site listings to appear and click Ok. On the Template Selection page, close the browser window. Do not click OK. Once the new URL has been prepared, we can restore the marketing site to it with the following command: Smigrate r w -f mktbk.fwp The restore command produces a great deal of output, but should look similar to the following diagram. Craig Carpenter Page 5 of 8

6 We can verify the restore by navigating to where we should see the contents of the marketing site. Once verified, (and any other departmental sites are migrated over) we can delete the departments top level site therefore deleting the site collection. Using the command above, any sub site of marketing would also be migrated as the command simply takes the site collection hierarchy starting with the site specified, working it s way down. If we simply wanted the marketing site and not any sub site that was below it, we would need to use the relevant switch with the SMIGRATE command: Smigrate w -f mktbk.fwp -e This will backup only the site specified in the URL. Craig Carpenter Page 6 of 8

7 Scenario Two Migrating Between Stand Alone and Embedded Site Collections. Here is another common requirement, either it s decided that an embedded site collection would be better as a stand alone site collection or vice versa. It has been decided that all of the departmental sites should be managed by their own virtual server. It is therefore required that the current embedded site collection be moved to a stand alone collection. With this, the process is essentially the same as before: Use SMIGRATE to backup the top site in the site collection (and therefore the site collection). Prepare the new URL by creating a stand alone site collection but not applying a template. Use SMIGRATE to restore to the new stand alone site collection URL. Delete the old site collection. Issue the following command to back up the site collection: Smigrate w -f depbak.fwp This backs up all the sites in the departments site collection to the file depbak.fwp in the current directory. The next step here is to create a stand alone site collection. To do this: In IIS Management, create a new web site to host the site collection s top level site. Register the URL of the new web site in DNS. Open up SharePoint Central Administration from the SharePoint Portal Server program group on the start menu. On the Windows SharePoint Services page, click the Extend or Upgrade Virtual Server link. Select the name of the web site to extend. On the Extend Virtual Server page, select the option to Extend and Create a Content Database. On the Extend and Create Content Database page, enter the appropriate information and click Ok. Close the completion page. To restore to the new URL, issue the following command: Smigrate r w URL> f depbak.fwp u trainsbydave\administrator pw * For a newly extended virtual server the username and password options are required. Again, confirm correct restoration by navigating to the appropriate URL before deleting the original site collection. Also, as a stand alone site collection has been created, it must be listed and added as a content source at the Portal to help users navigate to the information. Craig Carpenter Page 7 of 8

8 Scenario 3 - Migration of a site collection from one portal to another portal. In this scenario, the requirement is to move or copy a site from one Portal to another. This could be as part of a planned migration of the existing Portal onto new hardware or it could be the need to move a completed site from a development Portal to the live Portal. In either case the process is essentially the same as in the previous scenario. We should, however, consider the following two points: Domain Permissions SMIGRATE does not perform a full fidelity backup, and therefore permissions are not carried over from the original site. As this is the case, we should not have problems with permissions when migrating a site from one Domain to another. Custom Web Parts Any custom web parts that are installed on the file system of the front end web servers will not be migrated with SMIGRATE. These web parts must also be deployed to the front end web servers of the Portal that you are migrating to. As stated, the process is essentially the same as in the previous scenarios, with the additional preparation step of deploying any custom web parts to the target Portal: Deploy any custom web parts used in the site to be migrated to the front end web servers of the target Portal. Use SMIGRATE to backup the required site and any sub sites. Prepare the new URL by creating a new site, but not applying a template. Use SMIGRATE to restore to the new stand alone site collection URL. Craig Carpenter Page 8 of 8