USMT, OST, and PST

USMT, OST, and PST

  • Comments 15
  • Likes

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: http://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="http://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 - http://support.microsoft.com/kb/297019):

<?xml version="1.0" encoding="utf-8" ?>
<migration urlid="http://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! http://support.microsoft.com/kb/2023591

 

Until next time.

- Ned “ends in t” Pyle

  • Hi,

    will this create "doubles " for the linked pst already migrated by the default migapp.xml?

    What will be new location of the non-linked PST after loadstate ?

    Thanks in advance

  • I was veeeeery tempted to let you find out yourself with testing.

    ^_^

    Nope.

    Same location.

  • OK, Thanks .

    I will go to test Now  ;-)

    I have a relativemove rule for the PST, I will see were they will go now...

  • Hi Guys,

    I'm trying to redirect my PST's from D:\PST to the default location for Office 2010 (Documents\Outlook Files) and whilst this works for both linked/unlinked PST's, i've noticed that linked PST's also get a copy created in C:\PST on the destination machine.  I created the reroute code in the Config.XML, here's what i've got.  

    <!-- This component migrates all PST files Found on Drives to Default location in Office 2010 -->

       <component type="Documents" context="User">

     <displayName>Component to migrate all PST Files</displayName>

     <role role="Data">

       <rules>

    <include filter='MigXmlHelper.IgnoreIrrelevantLinks()'>

               <objectSet>

                    <script>MigXmlHelper.GenerateDrivePatterns ("* [*.pst]", "Fixed")</script>

               </objectSet>

           </include>

    <locationModify script="MigXmlHelper.ExactMove('%CSIDL_PERSONAL%\Outlook Files')">

       <objectSet>

    <script>MigXmlHelper.GenerateDrivePatterns ("* [*.pst]", "Fixed")</script>

          </objectSet>

    </locationModify>

       </rules>

     </role>

        </component>

    I created this under Context "User", as using "UserandSystem" created the C:\PST folder (with copied PST's) irrespective of whether the PST's were linked or not.  (I found they were duplicated by searching the diag.XML File)

    Any idea why the linked PST's would also get created on C:\PST??

    Thanks!

  • Hi Jimc84,

    I'm not able to reproduce that issue using your XML (it also didn't work as you desired either though, more on this below), but I'd also need to have all your other XML files and scanstate/loadstate syntax. That gets into the "you should open a support case" territory.

    I used this syntax in a custom PST.XML and it worked as you wanted yours to work (I think):

    <?xml version="1.0" encoding="utf-8" ?>

    <!-- Migrates all the .pst files from the pattern above into the user documents folder -->

    <migration urlid="www.microsoft.com/.../pstconsolidate">

     <component type="Documents" context="user">

       <displayName>All .pst files to a single folder</displayName>

       <role role="Data">

         <rules>

           <include>

             <objectSet>

               <pattern type="File">D:\PST\* [*.PST]</pattern>

             </objectSet>

           </include>

           <locationModify script="MigXmlHelper.ExactMove('%CSIDL_PERSONAL%\Outlook Files')">

             <objectSet>

               <script>MigXmlHelper.GenerateDrivePatterns ("* [*.pst]", "Fixed")</script>

             </objectSet>

           </locationModify>

         </rules>

       </role>

     </component>

    </migration>

    Keep in mind also that move,relativemove, and exactmove are risky things to do for users. There are collision possibilities (same named file), personal data issues (I can now access someone else's file), and just the confusion to an end user of their folder and data disappearing.

  • Thanks NedPyle.  I see you excluded the 'MigXmlHelper.IgnoreIrrelevantLinks()' from your code (I included this after reading Article, technet.microsoft.com/.../ff383238(WS.10).aspx & specifically, Example 1 : Include a file extension in a known user folder) so i'll give that a try and see what happens.  Hopefully, that's the only thing that could be causing the C:\PST Folder to get created.

    Regarding using the Move, ExactMove, RelativeMove options, the fact we're moving from a 2 partition scenario (C: & D:) to a 1 partition scenario (C: only in Windows 7), we have to be able to move the PST files from D: Drive to somewhere else on C:.  I take your point however, this could be asking for trouble but i'm not sure how best we can avoid it as the PST's have to be moved and i thought the default location in Office 2010 might be the best place for those.

    However, if you had any other suggestion on how we could avoid this, i'd appreciate if you could pass it on

    Thanks!

  • Hey Ned, i'm still having no luck with this....

    You mentioned you'd need to take a look at my XML/Scanstate/loadstate Files to see where exactly the problem is, if you wouldn't mind taking a look, i'd really appreciate it.  How can i get these files to you?

    Thanks!

  • Hi,

    Open a support case, they will iron you out.

  • xc

  • Hi,

    Nice post!

    I'm nwe with USMT and have a question:

    Actually I've got some PST created by users on the c:\someWhere (USMT copy them very well).

    The problem is that I've got a PST that is on a mapped network share (and is linked to outlook). This PST is copied by USMT to C:\pstname (on destination computer).

    I don t want this pst to be copied but only beeing linked by the outlook on destination.$

    Do you have any advice please?

    Thanks in advance.

    Regards.

  • Hi Krevard,

    Try this sample code:

    <?xml version="1.0" encoding="utf-8" ?>

    <migration urlid="www.microsoft.com/.../pstsampleexclude">

     <!-- 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>

    As a side note: running PST files off of network drives is strictly unsupported and not recommended -

    297019 Personal folder files are unsupported over a LAN or over a WAN link

    support.microsoft.com/default.aspx

    So having USMT "fix" this for you by copying the PST locally may be a fortunate coincidence you should leave in place.

  • Big thanks for ure answer Mr. Ned "USMT" Pyle. :-)

    I'm aware that PST are not supported over LAN. The problem is that we have 5000 PC's and every user has 2 or 3 PST with their archives (received items 2005, received items 2006,...) because the exchange team allows only 50MB for mailBox.... We can't let those PST locally because if the disk crash the users will cry a lot. I'll have a talk with exchange admins I think..

    I found another solution this morning by using the switch /localonly (sorry). But I'll try to integrate your code. It is cleaner (I think) to do all I can in XML files.

    One more time: Thanks.

    Have a nice day.

  • Cool!

    Yeah, the PST situation is pretty gruesome. A possible alternative:

    Create a sceheduled task backup on your clients and deploy it through GPP. Have it only backup the client's PSTs and profiles, then copy those backups to a file server. Twice a week is probably enough.

  • SysTools OST Recovery software will help you to perform Outlook Exchange OST to PST after which you can easily access emails data. Also email convert OST to PST is easy and quick with this software package.

    http://www.ost-to-pst.com/

  • PDS OST converter software is the best Exchange OST recovery tool to repair offline OST files & easily export OST to PST mailbox. OST files become corrupted due to the breakdown of Exchange server correlation