The one item that had me stumped for the longest time was an error similar to:
Message :
Error: MapiExceptionInvalidParameter: Unable to modify table. (hr=0x80070057, ec=-2147024809)
Diagnostic context:
Lid: 55847 EMSMDBPOOL.EcPoolSessionDoRpc called [length=228]
Lid: 43559 EMSMDBPOOL.EcPoolSessionDoRpc returned [ec=0x0][length=660][latency=0]
Lid: 23226 --- ROP Parse Start ---
Lid: 27962 ROP: ropModifyRules [65]
Lid: 17082 ROP Error: 0x80070057
Lid: 27745
Lid: 21921 StoreEc: 0x80070057
Lid: 27962 ROP: ropExtendedError [250]
Lid: 1494 ---- Remote Context Beg ----
Lid: 1238 Remote Context Overflow
Lid: 21970 StoreEc: 0x8004010F PropTag: 0x67AA000B
Lid: 21970 StoreEc: 0x8004010F PropTag: 0x67870102
Lid: 21970 StoreEc: 0x8004010F PropTag: 0x668F0040
Lid: 21970 StoreEc: 0x8004010F PropTag: 0x668F0040
Lid: 21970 StoreEc: 0x8004010F PropTag: 0x668F0040
Lid: 21970 StoreEc: 0x8004010F PropTag: 0x668F0040
Lid: 21970 StoreEc: 0x8004010F PropTag: 0x668F0040
Lid: 21970 StoreEc: 0x8004010F PropTag: 0x668F0040
Lid: 21970 StoreEc: 0x8004010F PropTag: 0x668F0040
Lid: 21970 StoreEc: 0x8004010F PropTag: 0x67F60040
Lid: 48851
Lid: 21970 StoreEc: 0x8004010F PropTag: 0x67F60040
Lid: 51077 dwParam: 0x80000000
Lid: 65267
Lid: 40691
Lid: 5559 StoreEc: 0x80070057
Lid: 65015
Lid: 65439
Lid: 4302 StoreEc: 0x80070057
Lid: 1750 ---- Remote Context End ----
Lid: 26849
Lid: 21817 ROP Failure: 0x80070057
Lid: 29150
Lid: 20446 StoreEc: 0x80070057
There isn't a lot out there about this specific error code (ec=-2147024809). What I needed to do was look closer at the failurecontext value on the get-moverequeststatistics cmd.
get-moverequest -movestatus failed | get-moverequeststatistics | fl displayname, failurecontext
FailureContext : --------
Operation: IDestinationFolder.SetRules
OperationSide: Target
Primary (4ab2ab00-5026-4afc-a3b7-7218b79123e8)
Rules: [Rule: Condition: none; Actions: [RuleAction: OOFREPLY TemplateEID:[len=70, data=00000000AC565E
5C530D26488301777148092EDD07005EEBA9008B75314DB7DC5CF90CA05941000000213F5400009CF6ED1D2A5ED211BDCA00805FA783D10000012B9C4B0000], TemplateGuid:1ab18c24-2b21-11d3-bded-00805fa783d1, Flags:0]; Name ''; Provider: 'MSFT:TDX OOF Rules'; ProviderData: 00000000; ExecutionSequence: 50; Level: 0; StateFlags: 13; UserFlags: 2; IsExtended: False]
--------
Folder: '/Top of Information Store/Deleted Items/Inbox', entryId [l en=46,data=00000000AC565E5C530D26488301777148092EDD0100E2947E1FF163954C86F997BC4491CE1B00000361AB520000], parentId [len=46,data=00000000AC565E5C530D26488301777148092EDD0100E2947E1FF163954C86F997BC4491CE1B00000121862D0000]
Two items to pay attention to..
- Provider: 'MSFT:TDX OOF Rules'
- Folder: '/Top of Information Store/Deleted Items/Inbox'
So, this person has (at least) 2 Inbox folders and each have an "Out of Office" auto-reply rule configured on them. The MoveRequest tool won't allow me to modify the OOF table twice for the same mailbox. Running a '/cleanrules' on this mailbox only manages to delete their live rules, but doesn't hit this second Inbox.
To fix this.
Original Rules Data value |
- Open MFCMapi and logon to this person's mailbox. I grant my admin account full mailbox rights just to make sure.
- Double-click mailbox (not public folders) under Display Name to open.
- Expand Root Container -> Top of Information Store and find Inbox above.
- Scroll to near bottom and locate the PR_RULES_DATA key. Double-click to open it.
- In the Property Editor, I click into the BINARY field, type CTRL+A to select all of the data and hit DELETE to clear it out. This should effectively wipe the rules from this folder.
After cleaning out rules. - Now you should be able to resume the move request for this user.
No comments:
Post a Comment