In its simplest form, initiating archive migration is as easy as selecting an archive from the Archive Management page and marking it for migration. However, in large enterprises with tens of thousands of users, it can quickly become difficult to pick out the handful of archives that have failed to migrate from the 70,000 or more that are listed. As a result, we have developed an optional queue based approach that groups archives with a similar status and so help identify further actions that an operator may need to undertake before successful migration is achieved. The queue functions can be categorised in four ways:

 

Inactive Queues

Inactive Queues contain archives where migration will currently not be attempted for one reason or another. Archives located here continue to count against the discovery and migration figures that are found in the related status pages.

Not all attributes needed to undertake a successful migration may be identified during discovery. This may include the owner or details about the target location and further automatic process must first stamp the entry with the missing details. In cases such as this, an archive will sit in the Incomplete Queue until all required information has been obtained.

It may be necessary for an operator to temporarily suspend processing for an individual archive. This may be because the user has left the organisation or the target server has a technical issue, for example. In cases such as this, the archive can be moved into the Paused Queue.

Once an archive migration is 100% complete, it is moved into the Successful Queue.

 

In-progress Queues

In-Progress Queues contain archives where migration is actively either about to be attempted or has been attempted and needs to be retried once again.

The Outlook Plugin Queue has a very specific purpose. Archives located here will only ever be processed by the Outlook Plugin where the archive is attached to an instance of Outlook that has the plugin installed. It will never be attempted for migration by a remote agent.

In certain instances (when choosing delete from within our Opt-In functionality for example) that a messaging source will simply be deleted. the archive will remain in the Autodelete Queue until it has successfully been removed.

During normal archive migration, remote agents will only actively move messages when they are in schedule. The Run Now Queue can be used to force an archive to migrate even when a remote agent is idle. To prevent over utilisation of resources, the number of concurrent migrations is limited by the number of pre-defined threads. Placing an archive into this queue will instruct the remote agent to begin migration when it is next free to do so which is not necessarily immediately.

The Rescheduled, Retry and Unattempted Queues are all very similar as they will process archives when in schedule. When discovered, archives will generally automatically go into the Unattempted Queue. Migration will then be attempted and if successful, they will automatically be transferred to the Successful Queue. Where a migration fails for some reason it will be moved into the Retry Queue and then be reattempted automatically up to five times by default. If the migration of this archive continues to fail then it will be transferred into one of the Error Queues for further investigation. Once the cause of failure has been established and resolved, an operator would then move the archive into the Rescheduled Queue in order for migration to be reattempted. Items located in the Rescheduled Queue will be processed first and only when there are no more archives located here will the Retry Queue be processed. Again, only when there are no further archives here will the Unattempted Queue be processed. This provides a mechanism to ensure that archives that have been partially processed are fully migrated as quickly as possible, but that the remote agent does not sit idle when there are archives that could be attempted.

 

Error Queues

Error Queues contain archives where migration has been attempted and has failed for one reason or another. Where the reason can be established automatically, then the archive may be placed into the Corrupt, In Use, Inaccessible or Password Protected Queues. Where a failure does not fit into any of these categories (for example network or target server unavailability), than the archive is placed into the Awaiting Intervention Queue. An archive may be placed into the Inaccessible Queue for a number of reasons including: the source archive has been deleted, a file share no longer exists or the remote agent no longer has file level permissions to access the source folder. Not all queues are used for all archive types and generally failed archives are only ever moved to the Awaiting Intervention Queue. We have the ability to read password protected PST files for example and it is highly unlikely that an individual exchange mailbox or archive will be Corrupt, In Use or Inaccessible.

Once the reason for error has been resolved, the operator may choose to move the offending archive into another queue such as the Rescheduled, Paused or Trash Queues.

 

Other Queues

Other Queues contain entries that do not count against the discovery and migration figures that are found in the related status pages. This includes items that should be deleted for one reason or another and have therefore been placed into the Trash Queue.

File discovery has a number of different options for identifying PST files with thorough interrogation taking longer than simple identification based upon the file extension. Often during the discovery phase, archives are created for all files with a .PST file extension. However, other applications (including some drawing applications produced by Corel) also use the .PST file extension and should the entry be found not to be a PST file at a later date, then it is moved into the Incorrect Format Queue from where it will prevent rediscovery.

The Disabled Queue is similar to the Paused Queue discussed above except migrating statistics on related status pages are excluded.