Migration Tip of the Week: Scripting with PowerShell

Hi there,

 

This week I would like to share some guidance on automating your migration tasks using PowerShell. As you may already know Migration Suite for SharePoint (as well as other Dell SharePoint migration solutions) sports a very flexible command line interface. Most of the core migration tasks available in the user interface can also be executed from a batch script. Did you ever noticed that Generate Script button at the bottom of nearly every migration wizard in the tool? Click it to get a CLI equivalent of the migration task you are about to perform. Very neat!

 

While the Windows command shell and batch files are totally usable, I generally prefer to script my migrations in PowerShell. Let's look at a common scenario: I am migrating documents from SharePoint 2007 to 2010. My source SharePoint 2007 document libraries use custom metadata columns. In 2010, I have implemented a new custom content type and I need to migrate my documents into this content type and do metadata mapping for columns that do not match by name. I could easilly do document level migration in Migration Suite and remap documents the way I want, but I have hundreds of libraries in 2007, so it might be tedious to use the UI.

 

First off, I need to create a metadata mapping for my script. For that I drag a single source document to a precreated SP 2010 document library in Migration Suite. I won't actually migrate the file. I just need to define the mapping and save it so it can be used from a batch script.

 

On the Properties screen, I select the desired content type from the dropbox and adjust the column mappings:

Then click Save Template to save the mappings to a mvmap file on your disk.

 

Now it's time for some PowerShell fun!

 

With PowerShell supporting running external commands, it's very easy to call Migration Suite CLI from within PowerShell. There are multiple ways to invoke a command, but I'll show you the easiest and most straightforward approach. I recommend creating a PowerShell script, which is reusable and easy to modify. Personally i prefer using variables for parameters to make edits easier (these can be passed into the script too), but you can get by with a one-liner if you want.

 

Fire up PowerShell ISE or Notepad and paste the following lines in (it is also attached to this post for your convenience):

 

## Quest installation path

$QuestPath = "c:\Program Files (x86)\Quest Software\Migration Suite for SharePoint\quest"

 

## Source site URL

$SrcWeb = "http://sp2007/sites/team"

 

## Target site URL

$TrgWeb = "http://sp2010/sites/root"

 

## Source list name

$SrcList = "Specifications"

 

## Target list name

$TrgList = "Specs"

 

## User name

$User = "contoso\applebee"

 

## Password

$Pwd = "1"

 

## Metadata Mapping

$MetaMapping = "C:\MyScript\specs.mvmap"

 

## Log File

$Log = "C:\MyScript\log.xml"

 

## Go!

& "$QuestPath\jre\bin\java.exe" -jar $QuestPath\plugins\org.eclipse.equinox.launcher_1.0.100.v20080509-1800.jar -cmd copyitems -srcsite $SrcWeb -srclist $SrcList -trgtsite $TrgWeb -trgtlist $TrgList -srcuser $User -srcpass $Pwd -trgtuser $User -trgtpass $Pwd -overwritebehavior dont_copy -mapping $MetaMapping -log $Log -noSplash >output.txt 2>&1

 

As you can see it is the last line in the script that actually does all the work by invoking the copyitems command for the source and target libraries. We supply the metadata mapping template using the -mapping attribute and instruct the tool to log to the file in the same directory. If you are familiar with classic Windows shell batch mode, you will recognize the last part, which redirects standard console output and errors to output.txt.

 

You might be wondering why the script uses a scary-looking Java launcher instead of QuestDM.exe as in auto-generated CLI scripts? The answer is that depending on your specific OS configuration, QuestDM.exe may run asynchronously. That makes scripting a bit more challenging, because you need to monitor the background process to understand when you are done. Using the java launcher solves this problem and the script will execute synchronously.

 

Ok, now just change the values in the script to ones that match your setup and save the script as a PS1 file. You can run it from the PowerShell prompt as follows (this article is a great resource of additional information on running PS scripts):

 

.\MyScript.ps1

 

When the script completes, you can examine the log file in Migration Suite (View | Log Viewer | Load). The output.txt contains a detailed progress log that can be useful for troubleshooting.

 

Happy scripting!

MyScript.ps1_5F00_.zip

About the Author
Alex Kirillov
Product Manager with the Microsoft Platform Management group