Do you wonder if your IT business is truly profitable or if you should raise your prices? Learn how to calculate your overhead burden using our free interactive tool and use it to determine the right price for your IT services. Start calculating Now!
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.
Do more with
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
Not sure if this will work, but worth a shot:
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
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
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
The issue persists after using the /cleanrules and /cleanserverrules switches. As well as manually creating and disabling the Out of Office message.
It's rapidly starting to look like an export to pst job.
You could export all the X500 addresses using a command such as:
Get-ADUser -SearchBase “OU=usersOU,DC=domain,DC=l
Afterwards you can replace any missing or incorrect X500 addresses so that replies to previous emails still work.
You could export all the X500 addresses using a command such as:
Get-ADUser -SearchBase “OU=usersOU,DC=domain,DC=l
Afterwards you can replace any missing or incorrect X500 addresses so that replies to previous emails still work.
Premium Content
You need an Expert Office subscription to comment.Start Free Trial