Client Driven PST Migration Process Explained in Detail

Article: 100002198
Last Published: 2014-08-13
Ratings: 1 0
Product(s): Enterprise Vault

Problem

The following article will explain the client driven PST migration process.

 

Solution

Enabling a user for Client-Side PST Migration:

  1. Select the Personal Stores node in the PST, select "Enable Client-Driven Migrations" from the action menu and pick the mailbox you wish to enable.
  2. Enable minimum client tracing and start Outlook for the appropriate mailbox. Open the client log file and verify that Desktop Settings contains: "PSTImportEnabled = 1". You should also see "PST Importer started" and "PST Importer sleeping for 1 minutes" in the trace - this denotes that the new PST migration thread in Outlook has started.
  3. You can also enable a user for client-side migration by setting the following registry key: HKEY_CURRENT_USERSoftwareKVSEnterprise VaultClientPSTImportEnabled = 1 [DWORD]. Setting this key to '0' disables PST migration. Note that this registry will override any enabled settings made in the VAC (as in step 1).

Locating PST's :

  1. When the PST migration thread starts, it contacts the server to obtain the list of known PST files for the computer and the PST policy settings. This is denoted in the client trace with: "Retrieving PST information from server".
  2. The thread then checks for any PST files that are still being migrated from a previous Outlook session. If any are found, the migration process will continue for these.
  3. By default the client will search the computer every week for PST files. This period can be changed by setting the Desktop Setting "PstSearchInterval" whose value is in days.
  4. The thread checks the reg key: HKEY_CURRENT_USERSoftwareKVSEnterprise VaultClientLastPSTSearch to see when the last PST search was made.
  5. If it is time to perform another search (or if a search has never been done) the thread will search the registry for any PST files in the user's MAPI profile(s) and located locally on the user's computer.
  6. When the registry search is complete, the thread will recursively search either all the local fixed disks, or just the user's Documents and Settings folder for PST files - depending on what is set in the PST Migration policy "Restrict search to PST files under users' 'Documents and Settings' folder".
  7. The client trace will log each folder that is searched and any PST files that are found.
  8. When the search is complete, the list of found PST files is sent to the server and are inserted into the PST Files database table.
  9. The HKEY_CURRENT_USERSoftwareKVSEnterprise VaultClientLastPSTSearch registry key is then set with the current date.
  10. The thread re-reads the server list of PST files (that will include the files just found by the search).

Migrating PST files :

  1. The thread looks for a PST file from the server list that is ready to be migrated and is in the user's current MAPI profile (if none of the PSTs are in the profile, then one will be selected from disk). This is logged in the client trace "Starting upload of PST: {FILENAME }"
  2. An XML file is then generated under the path:
  3. Documents and SettingsfootecLocal SettingsApplication DataKVSEnterprise Vault{site id }PSTImportPSTContents_{FILEID }.xml. This file is populated with the contents of the PST which each item's MAPI entryid and a sequential index number.
  4. The XML contents file should honour the PST policy setting of whether to include items in the Deleted Items folder.
  5. Once the XML contents file has been generated, a PST chunk file is created under the path:
  6. Documents and SettingsfootecLocal SettingsApplication DataKVSEnterprise Vault{site id}PSTImportPST{FILEID }_{CHUNKNUM }.db
  7. Using the XML contents file, items are copied from the source PST file into the PST chunk file based on the sequential index number.
  8. Once the size of all items copied into the chunk is greater than 10MB, or no more items are left in the source PST file, the PST chunk file is compressed and then uploaded to the server.
  9. When the chunk file is successfully uploaded, the client records its progress by writing the following registry keys (all under HKEY_CURRENT_USERSoftwareKVSEnterprise VaultClient{site id}PSTImport{PST fileid }:
    • LastCopiedChunk - the id of the last chunk to be successfully uploaded to the server
    • LastItemNum - the index number of the last item to be copied into the last PST chunk to be successfully uploaded
    • FailedItems - a running total of the number of items that could not be copied from the source PST file into the PST chunks
  10. The PST chunk file is then deleted and the client then checks with the server as to whether the PST chunk has been migrated. If the chunk has not yet been migrated, "PST{FILEID }_{chunk num }.db has not migrated. Retry in 1 minute" is logged to the client trace, and the thread waits for a minute before asking the server again.
  11. This process then repeats until there are no more items left in the source PST. The client then notifies the server that there are no more PST chunks left to send.
  12. The PST file is then removed from the user's MAPI profile (if it exists there) and marks the PST file as read-only.

 Deleting PST files :

  1. The thread will then sleep for a minute (this is configurable using the new Desktop Setting "PSTImportPauseInterval") and then re-reads the PST file list and status from the server.
  2. If any PSTs in this server list are marked as 'ready to be deleted', the client will delete the PST file and notify the server of the deletion.
  3. The whole process is then repeated with the next available PST file.

Was this content helpful?