USMT, OST, and PST

  • Article

Ned here again. Do you remember time before email in the office? It’s been a while now. Email isn’t an option these days any more than a phone. And since Exchange has reached around 65% market share, odds are decent that you’re using some version of Outlook. If you’re planning on migrating to Windows 7 with USMT 4.0, you likely have two questions:

  1. How can I get Outlook OST’s to migrate?
  2. How can I get Outlook PST’s to migrate?

Updated April 16, 2012 to be more complete

OST migration

I am just going to rip the bandage off here, so grit your teeth: you cannot migrate Outlook OST files with USMT. USMT makes no special allowances for OST files because the Outlook team does not support those files moving between computers; they were never designed for portability and Outlook’s developers don’t want anyone copying them around. The only supported way to get an OST file is for Outlook to create it.

If you create a custom Include XML file that copies over OST files then Outlook may state the OST is invalid or that it cannot be opened. Please don’t call us asking for workarounds: this is expected behavior and there is absolutely nothing that the USMT or Outlook support teams can do. The OST may appear to work also; you got lucky for now, but there may be buried badness in that file that rises up someday like a mail-enabled Dracula – no one knows.

And it's not just me saying this: https://technet.microsoft.com/en-us/library/cc179110.aspx#BKMK_MigrationConsiderations

PST migration

By default, USMT 4.0 migrates PST files that are linked to a user’s Outlook profile. This is done through internal USMT functions named SetPstPathInMapiStruct and UpdateMvBinaryMapiStruct which is called from within migapp.xml.

What this means is that PST files which are simply stored on the drive but not actually connected to Outlook might not migrate when using /i:migapp.xml and /i:migdocs.xml.  For example, if a user has a PST file store in their c:\users\someuser\appdata\local\microsoft\outlook folder: USMT doesn't just copy that folder's contents willy-nilly; after all, those are mostly local per-computer settings and data, and just blasting them onto another computer could cause problems.

It’s very possible a user is keeping those around for archive purposes, though. Migdocs.xml will gather customer folder contents from the roots of drives with little though to their contents, but you may need some XML to target PSTs appropriately and surgically. Consider this scenario, where the archive.pst and nov2009on.pst are not attached to Outlook, and are just loose files on the computer:

image

If you just wanted the c:\pst copy, you get it for free as long as you use migdocs.xml. In order to migrate  all of those PST files though, you’ll need to use a custom XML override. Here is a sample that will gather all PST files from all fixed drives, regardless of their location:

<?xml version="1.0" encoding="utf-8" ?>
<migration urlid="https://www.microsoft.com/migration/1.0/migxmlext/pst">
<component type="Documents" context="UserAndSystem">
<displayName>All PST migrated from all fixed drives, regardless of location</displayName>
<role role="Data">
<rules>
<include>
<objectSet>
<script>MigXmlHelper.GenerateDrivePatterns ("* [*.pst]", "Fixed")</script>
</objectSet>
</include>
</rules>
</role>
</component>
</migration>

Paste that into Notepad and save as PST.XML into your USMT folder. When you add that to your scanstate and loadstate command-lines with /i:pst.xml then all fixed drive PST files will be migrated. You could also paste it into Visual Studio 2008 Express, nudge nudge.

Here's another sample XML, which has the added bonus of not accidentally copying PST files that a user connected to Outlook through a UNC path (which is unsupported except for one small scenario, by the way - https://support.microsoft.com/kb/297019):

<?xml version="1.0" encoding="utf-8" ?>
<migration urlid="https://www.microsoft.com/migration/1.0/migxmlext/pst">
<!-- This component migrates .PSTs except for ones on the network-->
<component type="Documents" context="UserAndSystem">
<displayName>All PST files migrated from all fixed, no PST’s migrated from network, regardless of context or outlook registry catalog settings</displayName>
<role role="Data">
<rules>
<unconditionalExclude>
<objectSet>
<script>MigXmlHelper.GenerateDrivePatterns ("* [*.pst]", "Remote")</script>
</objectSet>
</unconditionalExclude>
<unconditionalExclude>
<objectSet>
<pattern type="File">\\* [*.pst]</pattern>
</objectSet>
</unconditionalExclude>
<include>
<objectSet>
<script>MigXmlHelper.GenerateDrivePatterns ("* [*.pst]", "Fixed")</script>
</objectSet>
</include>
</rules>
</role>
</component>
</migration>

Side note: the migXmlHelper.GenerateDrivePatterns option allows me to avoid hard coding paths, drive letters, or non-fixed storage. It’s something you should get comfortable with as it’s extremely useful in environments with non-standard images and users roaming freely with USB thumb drives. Since you’re going to Windows 7, don’t forget about “BitLocker to go” for those scenarios!

Another side note: Make sure you are using latest USMT 4.0 so that you capture Outlook 2010 settings correctly! https://support.microsoft.com/kb/2023591

 

Until next time.

- Ned “ends in t” Pyle