次の方法で共有

USMT, OST, and PST

  • [アーティクル]

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

Comments

  • Anonymous
    October 28, 2010
    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

  • Anonymous
    October 28, 2010
    I was veeeeery tempted to let you find out yourself with testing. ^_^ Nope. Same location.

  • Anonymous
    October 29, 2010
    OK, Thanks . I will go to test Now  ;-) I have a relativemove rule for the PST, I will see were they will go now...

  • Anonymous
    November 04, 2010
    The comment has been removed

  • Anonymous
    November 04, 2010
    The comment has been removed

  • Anonymous
    November 09, 2010
    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!

  • Anonymous
    November 19, 2010
    The comment has been removed

  • Anonymous
    November 19, 2010
    Hi, Open a support case, they will iron you out.

  • Anonymous
    November 25, 2010
    xc

  • Anonymous
    November 25, 2010
    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.

  • Anonymous
    November 29, 2010
    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.

  • Anonymous
    December 01, 2010
    The comment has been removed

  • Anonymous
    December 01, 2010
    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.

  • Anonymous
    December 28, 2010
    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/

  • Anonymous
    January 13, 2011
    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

  • Anonymous
    September 03, 2015
    Thanks dear to solve my problem... Again thanks