Although there are PST files to migrate the following message is seen in the Client Trace log 'PST Importer sleeping for 60 minutes (there is no work to do)'

Article:TECH55043  |  Created: 2009-01-15  |  Updated: 2013-10-16  |  Article URL http://www.symantec.com/docs/TECH55043
Article Type
Technical Solution

Product(s)

Environment

Issue



Although there are PST files to migrate the following message is seen in the Client Trace log 'PST Importer sleeping for 60 minutes (there is no work to do)'


Error



PST Importer sleeping for 60 minutes (there is no work to do)


Solution



The following steps are required to troubleshoot all Client-Driven PST Migrations:

1. Delete the following registry key if exist HKEY_CURRENT USER\Software\KVS\Enterprise Vault\Client\LastPSTSearch
2. Enable a Client Trace with logging set to 4 and open Outlook. (See article 276094 in the Related Documents section)
3. Perform a Dtrace of Directory Service, PST Migrator Task, Migrator Server and W3WP on the Vault Server where the user's archive and Storage Service is running. (See article 276120 in the Related Documents section for more information on Dtrace)

Migrating PST files from a Network Share

1. Although the client-driven process is done by the client, the Directory Services still accesses the Universal Naming Convention (UNC) path of the PST file across the network.  If the account running the Directory Service (usually the Vault Admin account) does not have Local Admin rights to the Server in the UNC path, PST Importer on the client will report that there is no work to do.

2. If the PST Files are hosted on non-Windows file servers, such as UNIX/Linux, the PST files will not be migrated.

3. If the network shared PST file is not in the Microsoft Outlook profile, PST Importer will not migrate the file.  Ensure the PST file is in the Outlook profile.

4. If the network share is accessed through the drive letter of a home folder assigned by Active Directory (non-persistent), have the user attempt to map the drive and try the PST migration again.

5. If the following is seen in the Dtrace:

(DirectoryService) <1668> EV:M DirectoryService: ChunkPstFile: No access permission error on call to NetShareGetInfo. PST: \\FILESERVER1\user\SYMC\Personal Folders.pst

(w3wp) <3216> EV-M {UPDATEPSTFILES.EN_US} UpdatePstFile failed to get Administrative Share name for PST '\\FILESERVER1\user\SYMC\Personal Folders.pst'

This is because the UNC Path is virtual and is a part of a Distributed File Sharing (DFS) and is currently not supported.  To workaround the issue perform a Server side migration on the DFS server for those PST files.

Migrating PST files from a non-Network Share

1. The Enterprise Vault server that runs the Migrator task must have a version of Outlook that matches, or is later than the version that is on the client.  For example, if there are clients with Outlook 2003, the server must have Outlook 2003 and ensure Collaboration Data Objects (CDO) is installed in Outlook.

2. The PST search may have a longer time in between searches before it actively searches again.  This can be changed in the registry under HKEY_CURRENT USER\Software\KVS\Enterprise Vault\Client\LastPSTSearch.  Reducing the days will allow the search for PST files to occur more often.

3. The permissions on the end user vault/archive and also on the site PST Holding Folder may be incorrect. It has been seen that a PSTAdmin account is used to run the PST Migrator Task.  Since the Vault Admin should not be a Domain Administrator, it cannot reach across a domain.  The "PSTAdmin" can be placed in the Domain Administrators group without issue.  Make sure that it also has access to the Shared PST Holding Folder as well.
 

 
a. When Enterprise Vault archives items, it also converts the contents to Hypertext Markup Language (HTML) and indexes them. There is a default conversion timeout of 30 minutes for this process. Enterprise Vault makes three attempts to convert an item and can take up to 90 minutes before failing an item and moving on to the next one. If there are very large, or very complex items in a PST file, it can take a long time to migrate them all. If the content of the items are not needed to be indexed, then performance can be improved by lowering the conversion timeout to just a few minutes.
 

 
b. To change the conversion timeout:
 
On the Storage Service computer, set the string registry entry ConversionTimeout to the timeout in minutes. The entry must be under the following registry key:
 
HKEY_LOCAL_MACHINE\SOFTWARE\KVS\Enterprise Vault
 

 
c. Restart the Storage Service.
 

4. A 'chunk size' issue may occur because the PST migration flows through the webserver and the PST files are migrated in 10mb chunks.  This behavior can be modified in the web.config file.

 
a. Open the Enterprise Vault\webapp folder open the web.config file.  Locate the line below and increase or decrease the maxRequestLength.
 

 
<httpRuntime executionTimeout="90" maxRequestLength="10000"
 

5. Clear the entries from the Enterprise Vault server and try again.  

Other things to be aware of:

 
Migration Status
 
Meaning
 
Ready to Copy
 
The PST file has been located and added to the PSTfiles SQL table. However, no chunks have been copied down to the server yet because either the PST Migrator Task is still migrating a chunk from another PST from that user, the PST Holding folder is full (default is 5GB), a permissions issue on the PST Holding Folder, or a valid PST license does not exist.
 
Migrating
 
A chunk has been copied down and is in the process of being migrated into the Archive.
 
Completing
 
All chunks for that PST file have been migrated, and now post-processing is being done.
 
Completed
 
The PST file has been fully migrated and post-processing is complete.
 



 



Legacy ID



293453


Article URL http://www.symantec.com/docs/TECH55043


Terms of use for this information are found in Legal Notices