Mail Target Agent shows a warning about existing mailboxes. What is correct way to resolve this (4351545)

Mail Target Agent shows a warning about existing mailboxes. What is correct way to resolve this

MTA (Mail Target Agent) log contains the following:

"CMBMConn::SetMailboxInfoE2K Warning 4807 Cannot create mailbox /o=ABC/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=Fisrtname.Lastname on the target server because the mailbox already exist (ForbidMailboxDeletion = 1)."

Why does this happen?  The Knowledgebase has articles 72579 and 39393 explaining that Migration Manager cannot handle pre-existing mailboxes and how to work around the issue, but it was definitely the Quest tool that created the mailboxes.  Why does MTA consider them as pre-existing now?

User accounts are getting mail and mailbox enabled by directory synchronization.  Under the directory synchronization properties Specify Exchange Options there is a mailbox store specified for the creation of new mailboxes.  However, when dirsync mailbox enables the accounts it does not physically create mailboxes, it only uses the information to populate the Exchange attributes, e.g. MSExchangeHomeMDB, MSExchangeHomeServer, etc. 

This is the reason why Migration Manager can use the same mailbox store when mail enabling thousands of objects, as it will not consume any storage or bandwidth. 

At this stage the existing mailbox should be seen as a place holder, in fact the mailbox does not exist and has no size or data inside. 

A mailbox will be created physically at a later stage when the agent (MTA or CSA) logons into the mailbox for the very first time.  When configuring mail or calendar synchronization jobs one can specify the destination mailbox database.  The agent will then move the existing mailbox (the place holder) and it will create the mailbox on the server and in the database which has been specified in the calendar or mailbox collection settings. 

When creating a mailbox in target, Migration Manager uses a very sophisticated procedure and preserves the exact SOURCE_KEY value of the source mailbox (and of each folder inside). 

The MTA requires that the existing target mailbox have the same SOURCE_KEY for all of the system folders as the source mailbox.  It is impossible to re-create system folders if they already exist in current mailbox.  The only way to create system folders with specific SOURCE_KEYs is to pass a special binary blob, called 'System Mailbox Info', during the creation of a mailbox.  So if the MTA "finds" a mailbox in target where 'System Mailbox Info' isn't equal to the '

 

Once the ForbidDelMailbox parameter is changed from 1 (one) to 0 (zero), the MTA has the ability to delete the target mailbox.  However it is important to understand how the agent will proceed.

The agent will not delete all existing mailboxes.  The MTA will also never delete a mailbox which was already processed by an agent (CSA or MTA) and which has been already (partially or fully) synchronized.  But the MTA will delete an existing mailbox if the mailbox was created before QMM was implemented or mailbox was created via other means and the user (the owner of this mailbox) was processed by dirsync and his mailbox was added to mailbox synchronization collection, in this case after allowing mailbox deletion the MTA will delete an existing mailbox and all mail data inside this mailbox will be lost.

It is important to understand how it works in order to chose the best approach.  The MTA will only log on to a mailbox for which there is an existing PRV file.  This means the MTA will try to delete only those mailboxes for which there are PRV files waiting to be delivered.  Knowing this one can do the following:

1. Stop the MSA and NTA
2. Use the Service File Viewer and ensure the PRV files in queue are only for recipients whose target mailboxes can be safely deleted and re-created.

If there are any PRV files for already existing mailboxes and you don't want to delete those mailboxes, then removing those PRV files from the queue will ensure that the MTA will not log on to those mailboxes and will not delete them.  When accumulated PRV files have been processed, change the ForbidDelMailbox parameter back to 1 (one) and disallow mailbox deletion.  Then previously removed PRV files can be put back in the queue.

------------------------------------------------------

Knowing all this, it is a good idea to keep the time interval between mailbox enabling and between mailbox synchronization short.

Possible prevention step:  Immediately after directory synchronization mail and mailbox enables target accounts, create a Calendar Synchronization job with a collection that includes all mailboxes.  In this case it will be the CSA who creates the target mailboxes and there will be no issues with the MTA complaining about already existing mailboxes.

 

Notes: 1. In some environments there have been some concerns about allowing the MTA to delete mailboxes, as some non-regular attributes were already populated and some third party products were heavily relying on those attributes.  After allowing the MTA to delete one or a few mailboxes it was confirmed that MTA doesn't entirely delete the mailbox and all existing attributes.  Most of the attributes were preserved and no information was lots as the MTA just re-created some folders inside the mailbox (on the fly) and was able to proceed. 2. The Service File Viewer is part of the Migration Manager for Exchange Resource Kit and if not present it can be installed any time, the User Guide contains more information about this tool.  Using the Service File Viewer one can look up the PRV files and see the recipient for each file, the destination mailbox.