Does your Archiving task pause?

[Andrew_G_]

There's nothing more frustrating than waiting for something. And waiting. You know the sort of thing, a delayed train, a waiter who disappears when you want another drink. In some circumstances, this may very well be your Exchange Archiving Task though, which keeps pausing when everything else seems perfectly fine.

The problem comes to light when a mailbox is moved to (or from) an Exchange 2013 database from an earlier version.

When a user performs a manual action, such as an archive or restore, then the client posts a message on a queue to tell the Archiving Task to perform the action. The queue used depends on the Exchange Server the mailbox resides on, according to the information available to Enterprise Vault. This information is updated periodically by the Exchange Provisioning Task. If the mailbox is moved, and the user tries to perform an Enterprise Vault action before the Exchange Provisioning Task has updated the information, then that message goes to the wrong queue, and the wrong Exchange Archiving Task tries to perform it.

Prior to Exchange 2013, and assuming all the tasks had permissions to access all the Exchange Servers, then  it didn't actually matter, as far as the action was concerned. The Archiving Task simply asked to open the mailbox and MAPI connected us to the correct Exchange Server. This changes with Exchange 2013 due to its modern architecture and requirements for the MAPI profile used to connect to the Exchange Server. The profile used for Exchange 2010 does not work for connections to Exchange 2013 servers, so the Archiving Task for Exchange 2010 cannot open a mailbox on Exchange 2013.

Instead, MAPI gives a rather generic error, which typically occurs for temporary network issues, and so Enterprise Vault treated it as temporary condition and re-queued the message to be processed again. Additionally, since it  thought there was also a network problem, it paused the Archiving Task to allow the network to recover. In this particular case, of course, the error isn't temporary, and the pause/re-queue would continue and severely affect the performance of the Archiving Task trying to do the work.

11.0.0 CHF2 introduces a little more logic, so that when the generic  error is detected, the MAPI profile and Active Directory are checked to see if there is a mismatch between Exchange versions. If there is, then the message isn't re-queued, and the Archiving Task isn't paused. This also means the action isn't performed either, and will need to be redone once the Provisioning Task has updated the information.

Now, where's my glass of water?