PST Discovery and Migration in Powershell

Sounds crazy right? Doing a PST discovery and migration without a UI to guide you around and know what you’ve found. Once you see how simple it is using the the Simply Migrate Powershell module, you won’t be thinking it’s crazy for long.

There are many factors to a PST discovery and migration. So lets start with some basics. The first example will show how to scan a file server share looking for PST files.

N.B It is assumed that you are actively running a Batch Controller (In the following examples, BatchID 1 will be used)

PS C:\Program Files\Simply Migrate>New-SMJob -Source Discovery -SourceInput \\SERVERNAME\Share$ -BatchID 1

N.B I’ll not show the job creation output here, that’s for a more detailed explanation about the powershell modules, but you will get some output from the above that will show you the configuration of the job you just created. No action is required though.

The above cmdlet is going to start discovering PST files located anywhere in the \\SERVER\Share$ share. Nothing fancy there. So what’s it finding? And what’s it coming back with?

Let’s have a look at how we can see some data about our discoveries. (It’s worthy of note that the following can be performed while a discovery is running, or upon completion. Obviously, you’ll get the full result set once it is complete, and that is recommended)

PS C:\Program Files\Simply Migrate>$myfiles = Get-SMJob -jobid 3 -SourceMigrationTypes Discovery -ShowEntries
PS C:\Program Files\Simply Migrate\Scripts> $myfiles.Entries

EntryId            : 85b25239-d494-41d1-9fa2-fb93a92ed516
JobId              : 1
ItemStatus         : Complete
Size               : 204648
DiscoveryDate      : 9/19/2016 9:40:00 AM
Path               : \\SERVER\Share$\Some Folder\A PST File.pst
Name               : Personal Folders
FolderCount        : 56
MessageCount       : 1200
EmailCount         : 800
CalendarCount      : 150
TaskCount          : 60
ContactCount       : 140
OtherCount         : 50
Owner1             : User1@domain.com

N.B The above output has been truncated slightly for the article. There is quite a bit more information included, but for the purpose of this article, I’ll trim that output down and focus on getting the job done.

Actually, there is a point to note from the above command. You’ll see that I have specified a JobID in the syntax. I didn’t have to do that. If I had not, the cmdlet would have returned all PST Files discovered across all jobs. (Actually, there is more to it than that even, but that’s a big and powerful topic for another post. I’ll link to it when it’s released)

The key take away here, is that I have now performed a PST discovery on a server path, and returned important information about each of the files discovered making it easy to migrate the data now. But it’s only taken me 3 lines of Powershell to get here, and we are only a line away from setting off a migration of all of the data we found … like I mentioned elsewhere, it’s really that simple.

Let’s cover the normal caveats first. I’ve had a look at the output of each of the PST files discovered and confirmed that I am comfortable with the ownership of each of the PST files discovered. Had I not been happy with any, I can correct the ownership in a number of ways. I’ll address those in another article, but I can touch on a few points below within the migration steps.

First, I will address the fact that you don’t need to have done a discovery at all in order to perform a PST migration. A list of PST File paths and an owner in a CSV is enough to get things rolling. But I’ll show you what I would do with the above and you will see how easy it is if the source was a CSV file.

PS C:\Program Files\Simply Migrate>foreach ($item in $myfiles.Entries){New-SMJob -Source PSTFile -Sourceinput $item.Path -Target Exchange -TargetOutput $item.Owner1 -TargetCredential $creds -BatchID 1}

Now, you’ll see in the above that I have used a $creds variable as well. This can be serviced a few ways, but what we see most commonly is simply

PS C:\Program Files\Simply Migrate>$creds = Get-Credential

That will prompt for credentials, just use some that have the appropriate permissions to the target Mailbox. (For EWS, it’s just the Application Impersonation Role)

I hate to cut this short, but the above started migrating the PST files into the user’s mailboxes. Yeah, that’s it. But I’ll waffle a little longer here, as there are some nice bits that you might want to add and change to the cmdlet to do what you need.

Let’s say you wanted to migrate the PST data to a user’s online archive instead of the mailbox itself? Just Add a -TargetOption UseArchive to the end of the command above, and like magic, it will migrate to the archive mailbox instead.

What if the PST file is password protected? Don’t worry, PST Passwords can be ignored and data is migrated seamlessly.

What if I want the data from the PST files to go into a subfolder? Add -TargetFolder “My Amazing Folder” to the above command line and your PST File will maintain it’s original folder structure but start at a folder called “My Amazing Folder”. If it doesn’t already exist, we will create it at migration time.

Have a look around the help of the cmdlet for more interesting options within there, it’s a big topic, and the cmdlet is intuitive and powerful.

No Comments

Be the first to start a conversation

Leave a Comment