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.
Set-MailboxAutoReplyConfiguration –AutoReplyState Disabled –ExternalMessage $null –InternalMessage $null

Open in new window

Also completed mailbox repair requests successfully but still same mailbox move result.  
New-MailboxRepairRequest -Mailbox -CorruptionType ProvisionedFolder,SearchFolder,FolderView,AggregateCounts

Open in new window

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 -BadItemLimit 500 -AcceptLargeDataLoss

Open in new window

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.
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Ralph PickeringInfrastructure ConsultantCommented:
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.Microsoft • IPM.Note.Rules.ExternalOOFTemplate.Microsoft • IPM.Note.Rules.ReplyTemplate.Microsoft  
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.

gatorITSAuthor Commented:
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.
Ralph PickeringInfrastructure ConsultantCommented:
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.
Your Guide to Achieving IT Business Success

The IT Service Excellence Tool Kit has best practices to keep your clients happy and business booming. Inside, you’ll find everything you need to increase client satisfaction and retention, become more competitive, and increase your overall success.

gatorITSAuthor Commented:
The issue persists after using the /cleanrules and /cleanserverrules switches.  As well as manually creating and disabling the Out of Office message.
Ralph PickeringInfrastructure ConsultantCommented:
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=local” -Filter * -Properties SamAccountName,legacyExchangeDN | Select-Object SamAccountName,legacyExchangeDN | Export-CSV C:\UserExport.csv
Afterwards you can replace any missing or incorrect X500 addresses so that replies to previous emails still work.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
gatorITSAuthor Commented:
Only workaround available.  Good suggestions though.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.