-
Title
Existing Exchange 2010 mailboxes and Migration Manager agents handling of them - "forbiddelmailbox" LEGACY AGENTS ONLY -
Description
It is visible from the logs that Migration Manager agents are deleting mailboxes, even if those mailboxes have been created by Migriation Manager, by dirsync.
Why do the agents delete those mailboxes and why are they being deleted without having the agent to configured so?
Does this mean that the agent could possibly delete any mailboxes which already contain some mail data?
How do agents handle mailboxes which are already present on Exchange 2010 server? "Forbiddelmailbox"
Mail Target and Calendar Synchronization Agents do not synchronize target mailboxes that exist prior to exchange migration. Is there any way to change this behavior?The following error message is found in the MTA log:
2/7/2008 4:36:34 PM CMBMConn::SetMailboxInfoE2K Warning 4807 Cannot create mailbox '/o=organization/ou=organization unit/cn=Recipients/cn=username' on the target server because the mailbox already exist (ForbidMailboxDeletion = 1). -
Cause
Below is an excerpt from Exch User Guide which explains the behavior and how the ForbidDelMailbox is being used when migrating to Exchange 2010 (in combination with ForbidDelMailbox2010)
FOR LEGACY AGENTS ONLY -
Resolution
FOR LEGACY AGENTS ONLY
Synchronization Specifics in Exchange 2010How to Avoid Incompatible Mailboxes
An Exchange 2010 server may create unrequested empty mailboxes for mailbox-enabled users that have no mailboxes. This behavior was not present in previous Exchange versions.
The resulting mailboxes are incompatible with Migration Manager and cannot be used by it during Exchange migration. Instead of relying on Exchange to create mailboxes, you should delete such automatically created mailboxes and use mailbox creation settings in your migration project. Mailboxes created by Migration Manager are fully supported.
However, new Exchange 2010 mailboxes should not be deleted indiscriminately, because valid target mailboxes might be deleted in the process. The ForbidDelMailbox 2010 parameter has been introduced to facilitate cleanup.
Previously, the ForbidDelMailbox parameter in the mail target agent's INI file was the only setting responsible for preserving or removing target mailboxes whoseMailboxInfoparameter did not match the same parameter in the source mailbox. The ForbidDelMailbox parameter is a precaution against the deletion of mailboxes that are in actual use in the target environment. By default, it is set to 1 so that non-matched target mailboxes are not deleted.
The additional ForbidDelMailbox 2010 parameter affects only Exchange 2010 target mailboxes. This parameter can have one of the following values:
0 Delete the new mailbox, but only if it is empty.
1 Let the ForbidDelMailbox parameter define what to do with the new mailbox, but only if the mailbox is empty. Otherwise, do not delete the mailbox.The ForbidDelMailbox 2010 parameter is not included in the mail Target agent's INI file by default, and its value is assumed to be 0.
ForbidDelMailbox ForbidDelMailbox2010 Action for E2003 - E2010 Action for E2000 1 0 Mbx size = 0: delete mailbox. do not delete mailbox Mbx size not =0: do not delete mailbox 1 1 do not delete mailbox do not delete mailbox 0 0 or 1 delete mailbox. delete mailbox. First row is the default setting (ForbidDelMailbox=1 and ForbidDelMailbox2010=0)
Attached screenshot also demonstrates and explains all possible combinations of settings and what they will accomplish.
Changing the Setting
There are two way to change this Setting. One is temporary for the specific MTA and/or CSA experiencing the error and the second is across the whole of QMM.
The first way is to just edit the config.ini in the MTA and/or CSA folder and change the "ForbidDelMailbox" parameter from 1 (one) to 0 (zero). Modifying the config.ini on the affected MTA and/or CSA will only allow that specific MTA and/or CSA to clean up the issue. The next time the config.ini is written back to the target server, the config.ini will revert to the default setting for the "ForbidDelMailbox" parameter and act as a safety again.The second solution recommends a change to the parameter which has a universal affect on QMM. Make this change by selecting Tools | Options | Additional parameters for agent configuration files and adding "ForbidDelMailbox=0" or "ForbidDelMailbox2010=0" to Mail Target and Calendar agents. This will make all of the Mail Target and Calendar Synchronization Agents automatically delete any target mailboxes existing on target prior to migration.Note: This change will stay in force until it is changed back.Important: Despite the fact that the log file contains the entry "ForbidMailboxDeletion" newly created additional parameter should be "ForbidDelMailbox"Note: In order to see the Additional parameters for agent configuration files you need to enable it via the Windows Registry on the console. Open Regedit and navigate to HKLM\SOFTWARE\Aelita\Migration Manager\CurrentVersion\Exchange Data and create a new DWORD key (32 Bit, not 64 Bit). Name it "ShowAdditionalParameters" and set its value to 1.If you are running 64-bit system then the registry would be HKLM\SOFTWARE\WOW6432Node\Aelita\Migration Manager\CurrentVersion\Exchange Data
Registry Disclaimer
Quest software does not provide support for problems that arise from improper modification of the registry. The Windows registry contains information critical to your computer and applications. Make sure you back up the registry before modifying it. For more information on the Windows Registry Editor and how to back up and restore it, refer to Microsoft Article ID 256986 Description of the Microsoft Windows registry: http://support.microsoft.com/default.aspx?kbid=256986.** -
Attachments
-
Additional Information
This issue occurs only in environments where DSA mail and mailbox enabled the accounts but mail sync was started later, during this time a procedure or a process or something else triggered the creation of a mailbox. Knowing this such issues could be avoided by adjusting the steps and changing the approach, e.g. 1. Include users into sync scope only when ready to start with mail migration, allow DSA mail enable them and immediately add them to a collection so agent will be the first one who will log on to those mailboxes 2. Create a calendar sync job and include all users, after DSA mail enables them it will be the CSA who accesses the mailbox first and creates the mailbox. Mentioned above ideas are not official suggestions or recommendations and are published only as attempt to assist migration admins when making decisions and deciding about the strategy. Please see the following solutions for additional information on this issue. Solution 39393 - Is it possible to allow the deletion of target mailboxes just for a specific server? - https://support.quest.com/SUPPORT/index?page=solution&id=SOL39393 Solution 59804 - Mail Target Agent creating a warning about existing mailboxes and how to resolve the issue properly. - https://support.quest.com/SUPPORT/index?page=solution&id=SOL59804 Solution 10368 - How to Handle Target Mailboxes Existing prior to Exchange Migration using QMM (Quest Migration Manager) https://support.quest.com/SUPPORT/index?page=solution&id=SOL59804 Information
