I have a customer that is using a POP3/IMAP hosted server and Outlook as their client.
Outlook stores all the data in PST files when you attach it to a service like this. OST files are only for Outlook to Exchange. So I need to collect all the PST files from the desktops and send them to Office 365.
There are a variety of tools available to do this.
SysTools Outlook PST Locator
This tool finds the PST files on all the workstations in the domain by hitting the administrative share (\\computername\c$) and scanning it, for free.
For $29 it will also copy them.
I found out after paying for the tool that it wants to copy all of the files to ONE directory. So if there are two files of the same name in various locations on various machines, one wins. Which one, I don’t know. If the pst file is in use by Outlook, the tool will not copy the file, no surprise there, but there is no reporting that the tool was unable to copy the file.
So, as a free tool, it’s pretty good to perform a scan of what pst tools exist and where they are. As a paid tool, it’s not worth it.
Microsoft Exchange PST Capture 2.0
This tool is Microsoft’s tool that will do it all. Find all the PST files and dump them to a location of your choosing. The tool has a workstation agent that needs to get installed which also requires dot net 4.5 to be installed as a prerequisit. Since my customer does not have any software deployment tools, using group policy to push this out seemed very unsuccessful.
I am using the tool to push the PST files up to Office 365. The one “catch” is that the tool requires a 64 bit version of outlook to be installed on the workstation/server that the tool is running from. So I am using a windows 7 x64 virtual machines where I installed the 64 bit version of outlook, dot net 4.5, powershell 3.0 and finally the tool.
I can tell you that the tool works fine for pushing PST files to the target mailboxes in Office 365, but I can’t tell you about the agents.
I came up with my own soulution to get those PST files. The first tool told me that some people have multiple profiles on their pc, as in c:\users\John and c:\users\john.001, where one of those profiles is old and stale.
Also, I need to copy the PST file before the user starts Outlook and locks that file.
My solution was to use AutoIT and make an exe file out of the following code.
$datapath = @HomeDrive & @HomePath & "\Documents\Outlook Files\*.*"
$copyto="\\SRV-FILE01\MDrive\pstlog\" & @UserName & "\*.*"
FileCopy ($datapath , $copyto, 8)
The number 8 means to create the destination directory if it does not exist. So under the \pstlog\ folder, it will create the user’s name and then copy all the folders.
I put this the command
as the last line in the logon script batch file that everyone is already using. The “start” command doesn’t keep the command prompt open
Without the “start” command, the command prompt box stays open.
Since this homemade tool runs at logon time, Outlook is not open yet.
If I change the number 8 to a number 9, it will copy OVER the existing file, that way I get the latest file.
When I get close to cutover date, I will change the 8 to a 9 and get the latest pst files.
I found through testing that when I import the PST file multiple times using the Microsoft tool, it does NOT create duplicate messages, whew!!
Now, the only problem with this solution at this point is that if the outlook pst data file was created in a different location than the default, I will need to manually get that one.
Since the free tool found all instances of pst files, I’m pretty sure that everyone has them in the default location.
Overall, a pretty easy migration.