These issues can generally be separated in three categories: Client restrictions, Server restrictions, Ownership restrictions.
Client restrictions are best described as conditions where the root cause of the problem is sourced on a workstation machine. The challenge of these issues is that active troubleshooting requires not just a user's workstation, but also the user logged in as their account. This level of disruption is frequently undesired and sometimes unavailable. Most of these issues can be identified and resolved (or worked around) from the server but on occasion, these restrictions require a client log to be gathered or workstation access to better understand the full nature of the problem. Click the following for more information on how to retrieve the log from the console.
Some examples of specific client restrictions.
MMPSTEE is frequently chosen because of its ability to minimize the impact of a user experience during a migration. If configured, a user is able to access the data within their PST files during their migration. This is accomplished by making a snapshot copy of attached PST files. Sometimes there are issues related to this process that prevent PST files from being uploaded. Some examples of these issues are as follows:
- Client exclusions are not in place for DLP, AntiVirus, or indexing solutions
- Local space on the workstation is smaller than the PST file size that needs to be copied
- PST file locks outside of Outlook
- A second password on the PST is not yet authenticated
- Timeout occurs
When PST files are very large, actively used, or on a remote resource, these issues can be more prevalent. They are most commonly identified via the Admin Console. Request and review of a client log can provide more details as to the exact nature of the issue.
2) Registry Keys not being set
For a migration to run in snapshot mode, there are some registry keys that have to be set. When an agent sees a user is enabled for migration in snapshot mode, it checks to ensure that the registry keys required for the migration are set. If they are not set, and there is a problem setting these keys, or the keys are not configured to be set, then the migration for that user on that workstation will not start. When registry keys cannot be set, an event is logged in the MMPSTEE event viewer.
Click the following for more information on what registry keys the migration agent requires when in snapshot mode.
3) Discovery Expired
The discovery process is the act of identifying PST files for migration and collecting some metadata about those files. If a file was seen, but has stopped being seen for longer than the configured discovery expiration, that file will be disqualified for migration until rediscovered.
Common reasons for Discovery Expiration are as follows:
- Manual deletion of previously discovered PST file
- Workstation refresh
- User has been on an extended absence exceeding the expiration timeout
4) Migration agent not running
The Migration Agent is comprised of several components. It is possible for a file to continue to be discovered but the Migration Agent to have faulted or been deliberately killed. In these cases you will continue to see a current discovery date and a file will never reach the discovery expiration period. In this situation, the file will never attempt to upload. These issues can be identified because you will notice the discovery date continuing to be current but a request to reset the agent or collect logs will report back as already having been queued as seen below.
If this occurs, client side investigation may be required to identify root cause of this issue. Alternatively, a Forced Migration via a Central Upload Agent can be used to work around the issue.
5) Upload errors
Files attempting to upload but don't complete can delay a user's migration. If a poor connection is being used, or PST files are exceptionally large, attempting to upload them via BITS may be challenging and fail several times prior to being successful. These errors can be seen from the server in Events that are logged in MMPSTEE's consoles. Files impacted may also identified by reviewing the "Upload Status" of the files in either of the consoles.
Server configuration and health can also impact the ability to upload files. This section discusses some server specific settings or issues that will prevent the ability to upload PST files to the server.
The following are some examples of server restrictions that could impact the ability for a user's PST file to be uploaded.
1) User is not enabled
The first requirement to ensure a user is beginning to upload their PST file is that they are enabled for migration. Enabling a user for migration is done by setting the users Migration Priority to a value between 0 and 100 (by default).
2) BITS configuration
Sometimes BITS is unable to work appropriately. Most common BITS issues impact all users attempting to upload, although it is possible for certain conditions to occur which may result in a more limited scope of BITS issues. If all users are unable to upload try checking to ensure BITS uploads can occur.
3) Environmental configuration
There are several areas of the product configuration that can restrict or prohibit the ability of PST files to upload. The following table describes these values and where the issues can be seen.
|Concurrent Uploads||Restricts the number of items that can be uploaded and can result in PST files not being eligible for upload||Events logged on MMPSTEE will report instances of this restriction|
|Maximum Upload Size||Restricts the cumulative size of uploads permitted at a time and can result in PST files not being eligible for uploads||Events logged on MMPSTEE will report instances of this restriction|
|Space Constraints||Running out of space will prohibit functionality and running low on space can restrict the number and volume of data eligible for upload||Events logged on MMPSTEE will report low space conditions and automatic settings adjustments |
|Upload PSTs marked for deletion||Specifies the upload behavior of files designated for deletion||Environment > Advanced setting selection determines how files are impacted|
|Upload PSTs marked as "Not Owner"||Specifies the upload behavior of files where users have selected the "Not Mine" option during an interactive migration||Environment > Advanced setting selection determines how files are impacted. Affected files will be associated with "Ownerless" user account|
4) User Postponement
In an interactive migration under a default or near default configuration, it is possible for a user to postpone the migration of their PST files by selecting the appropriate action when prompted to Migrate Now or Postpone. This will result in PST files not being uploaded despite being seen on a workstation. At the time of authoring, there is no easy way to determine if a user has postponed their migration from the server and frequently it is necessary to have a conversation with the user to determine if this was the action taken. Review of the number of Postponement days remaining can imply a postponement has occurred.
If a user mistakenly postponed their migration, a MMPSTEE Operator could remove their postponement in a console by going to Manage > Users and selecting the appropriate user. Once selected, expand the Actions menu and select the option to Clear Postponement as seen below.
5) Central Upload Agent (CUA) related challenges
The use of the CUA can add a lot of benefits to a migration project but can change the way some files are migrated. This added complexity has to be taken into consideration when troubleshooting upload issues when a CUA is installed and enabled. The CUA operates against a defined "Location" as configured in MMPSTEE and specific servers where PST files are located. For more information on setting up a CUA please refer to the MMPSTEE Deployment guide.
As the CUA runs remotely to the user session and workstation, it cannot take advantage of open connections the mail client may have with a PST file. It is therefore much more susceptible to conditions where a PST file is locked by another process. A persistently locked file attempting to be uploaded by a CUA with no user Migration Agent involved may have issues uploading. Review of the CUA's log file will show failed attempts to upload the PST file due to the file being locked by another process.
The CUA requires permissions to reach the file in its location. If on a file server, this can be the shared UNC paths of concern. The CUA can also be leveraged in a "Forced Migration." On a workstation, the account running the CUA will require access to the hidden administrative share associated with the discovered file.
Ownership restrictions are issues identified during discovery or user file selection that relate to the determination of the owner of a file.
1) Owner Conflicts
The most common instance of this type of restriction is an "Owner Conflict". This condition occurs when two or more users identify the same PST file during the discovery process. This results in an automatic conflict of file ownership and will prevent a file from being uploaded. These issues are easily identified via the MMPSTEE events or by review of the Manage > Owners section of a console.
If a specific user is seen causing many owner conflicts regularly, they can be grouped in an appropriate "User Type" so that their discovery results will be ignored going forward. This can prevent recurrence of this issue but will require a proper discovery period for these users at the end of a migration project.
2) Ownerless and Deleted files
Files which are marked as Ownerless files or files which have been marked for deletion during the an interactive migration or by the Administrator may also not upload as expected. The options to upload Ownerless or Deleted files are located in the Migration Agent portion of the Advanced tab under Settings > Environment. If the options to "Upload PSTs marked for deletion" and "Upload PSTs marked Not Owner" are deselected, files marked for deletion or associated with the "Ownerless user" account (Settings > Environment > General) will not be uploaded.
3) Shared Machines
Shared computers get an "honorable mention" in this article. Not because they in themselves cause issues with users uploading PST files, but the transient nature of their use may make it hard to capture data off any given workstation. Frequently shared machines result in PST files which are orphaned under a user profile that has not been active for a period of time or is seen on a piece of removable media periodically on machine to machine. These issues can be hard to identify except to know that these machines are shared. Each issue has its own symptoms. A way to see if you may be dealing with a shared computer is to select show all files on the same computer under Manage > Files > Actions and review the results to confirm that many files from many users were discovered on the resultant machine.