asked on
Exchange Mailbox Moves - Fail due to AutoReply (2010)
We’re encountering issues with a small percentage of move requests on a mailbox rebalancing project. There is no upgrade or move between different version of Exchange involved - just going from one mailbox database on one server to another mailbox database on another server – both Exchange 2010 SP3.
The moves fail almost immediately and the following event is recorded:
Event 8533:
“A problem occurred while getting the properties for the automatic reply message from FirstName LastName.
Error code: -2147221233.
Try to clear the rules or run ISINTEG to check for any problem in the database "Mailbox Database 01".”
We found that the auto-reply integrity was in a failed state in many cases but even after disabling it and checking the status again (reporting clean now), it still fails.
Also completed mailbox repair requests successfully but still same mailbox move result.
Although it doesn’t appear that corrupted messages are the issue, we also increased bad item limit to a high value with accept data loss.
Again, no change.
Any other thoughts? We are trying to avoid exporting to PST and re-creating mailboxes due to potential undeliverables involving AutoComplete, replies to previous messages, etc.
The moves fail almost immediately and the following event is recorded:
Event 8533:
“A problem occurred while getting the properties for the automatic reply message from FirstName LastName.
Error code: -2147221233.
Try to clear the rules or run ISINTEG to check for any problem in the database "Mailbox Database 01".”
We found that the auto-reply integrity was in a failed state in many cases but even after disabling it and checking the status again (reporting clean now), it still fails.
Set-MailboxAutoReplyConfiguration user.name –AutoReplyState Disabled –ExternalMessage $null –InternalMessage $null
Also completed mailbox repair requests successfully but still same mailbox move result.
New-MailboxRepairRequest -Mailbox user.name -CorruptionType ProvisionedFolder,SearchFolder,FolderView,AggregateCounts
Although it doesn’t appear that corrupted messages are the issue, we also increased bad item limit to a high value with accept data loss.
New-MoveRequest -Identity user.name -BadItemLimit 500 -AcceptLargeDataLoss
Again, no change.
Any other thoughts? We are trying to avoid exporting to PST and re-creating mailboxes due to potential undeliverables involving AutoComplete, replies to previous messages, etc.
Exchange
Last Comment
gatorITS
ASKER
Thank you for the reponse. This potential solution looked promising but attempted with two mailboxes without success. There is one mailbox that I attempted all classes related to Rules but the moves are still failing.
Perhaps run outlook.exe /cleanrules (or /cleanserverrules) on one of the problem mailboxes? If you can afford to scrap the rules that have been set up, that is.
https://support.office.com/en-us/article/Command-line-switches-for-Outlook-2010-ce2b9143-ceca-48ac-bffc-c3059a4c5919
https://support.office.com/en-us/article/Command-line-switches-for-Outlook-2010-ce2b9143-ceca-48ac-bffc-c3059a4c5919
ASKER
The issue persists after using the /cleanrules and /cleanserverrules switches. As well as manually creating and disabling the Out of Office message.
ASKER CERTIFIED SOLUTION
THIS SOLUTION ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
ASKER
Only workaround available. Good suggestions though.
Download the latest MFCMAPI 32 bit executable
1. Configure Outlook for the affected user in Online Mode.
2. Make a note of the Internal and External OOF Template.
3. Make sure the OOF Settings are disabled from Outlook.
4. Launch MFC MAP1.
5. Session Logon and select the appropriate Outlook Profile.
6. Double Click the Mailbox of the Affected User.
7. Expand Root Container.
8. Expand Top Of Information Store.
9. Right-Click the Inbox folder and select “Open Associated Contents Table”.
10. Once user is in the associated Contents Table, user has to sort on the “Message Class” column.
11. The valid classes for OOF messages are: • IPM.Note.Rules.OOFTemplate
12. To delete, simply select the OOF Template, right click the instance, and select “Delete Message”. (Deletion Style: Permanent Delete passing DELETE_HARD_DELETE (unrecoverable).
13. Close MFCMAPI properly by selecting Exit to each screen that has been presented. On the Final dialog, where the actual tree is located, select the Session menu then select “Logoff” (this will clear the windows). Then from the file Menu, select Exit.
Source: http://h20564.www2.hpe.com/hpsc/doc/public/display?docId=mmr_kc-0110035