Error – move Mailbox from Exchange 2003 to Exchange 2010
Bei einer Migration von einer Exchange 2003 Umgebung auf Exchange 2010 bin ich auf ein ungewöhnlichen Fehler gestoßen. Als die ersten Mailboxen von Exchange 2003 auf die neue Exchange 2010 Umgebung verschoben wurden, kam es bei einigen Mailboxen zu Fehlern wie folgendes Log zeigt:
Log Name: Application
Source: MSExchange Mailbox Replication
Date: 17.6.2011. 11:29:28
Event ID: 1110
Task Category: Request
Level: Warning
Keywords: Classic
User: N/A
Computer: ExDB01.testing.local
Description:
The Microsoft Exchange Mailbox Replication service was unable to apply search criteria to a search folder. The error was ignored.
Request: Primary (48706c9c-ad51-40d6-98b1-eb11039385e5)
Folder name:/To-Do-Search
Error: MapiExceptionInvalidEntryId: Unable to SetSearchCriteria. (hr=0x80040107, ec=-2147221241)
Diagnostic context:
Lid: 26926
Lid: 22830 StoreEc: 0x80040107
Lid: 32558
Lid: 18222 StoreEc: 0x80040107
Lid: 26414
Lid: 19246 StoreEc: 0x80040107
Lid: 18094
Lid: 27310 StoreEc: 0x80040107
Lid: 32382
Lid: 31358 StoreEc: 0x80040107
Lid: 16510
Lid: 31358 StoreEc: 0x80040107
Lid: 16510
Lid: 31358 StoreEc: 0x80040107
Lid: 26750
Lid: 22654 StoreEc: 0x80040107
Lid: 22161
Lid: 19089 StoreEc: 0x80040107
Lid: 18065
Lid: 26257 StoreEc: 0x80040107
Context:
--------
Operation: IDestinationFolder.SetSearchCriteria
OperationSide: Target
Primary (48706c9c-ad51-40d6-98b1-eb11039385e5)
Restriction: Restriction: AND[AND[PROPERTY[ptag:ParentEntryId, NotEqual, val:[Tag:ParentEntryId, Value:cb = 22, lpb = 0001020000000001A268000000000000000000000000]]; PROPERTY[ptag:ParentEntryId, NotEqual, val:[Tag:ParentEntryId, Value:cb = 22, lpb = 00010A00000005B10002000000000000000000000000]]; PROPERTY[ptag:ParentEntryId, NotEqual, val:[Tag:ParentEntryId, Value:cb = 22, lpb = 0001020000000007DC6E000000000000000000000000]]; PROPERTY[ptag:ParentEntryId, NotEqual, val:[Tag:ParentEntryId, Value:cb = 22, lpb = 0001020000000001A266000000000000000000000000]]; PROPERTY[ptag:ParentEntryId, NotEqual, val:[Tag:ParentEntryId, Value:cb = 22, lpb = 00010400000002548DCA000000000000000000000000]]; PROPERTY[ptag:ParentEntryId, NotEqual, val:[Tag:ParentEntryId, Value:cb = 22, lpb = 00010400000002548DCB000000000000000000000000]]; PROPERTY[ptag:ParentEntryId, NotEqual, val:[Tag:ParentEntryId, Value:cb = 22, lpb = 00010400000002548DCC000000000000000000000000]]; PROPERTY[ptag:ParentEntryId, NotEqual, val:[Tag:ParentEntryId, Value:cb = 22, lpb = 00010400000002548DC9000000000000000000000000]]]; AND[EXIST[ptag:237764866]; BITMASK[ptag:MessageFlags, EqualToZero, mask:0xC]]]
EntryIDs: [[len=46, data=0000000020EAD2782070D3118CB000105AF14FD70100712D5DEA935BD3118CA900105AF14FD700000001A2620000]]
Flags: Restart, Recursive, NonContentIndexed, FailOnForeignEID
--------
Search folder: '/To-Do-Search', entryId [len=46, data=0000000020EAD2782070D3118CB000105AF14FD701008A7E0BD32E921449A8B66F31569AEBF10000002E58E60000], parentId [len=46, data=0000000020EAD2782070D3118CB000105AF14FD70100712D5DEA935BD3118CA900105AF14FD700000001A2610000]
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="MSExchange Mailbox Replication" />
<EventID Qualifiers="32772">1110</EventID>
<Level>3</Level>
<Task>2</Task>
<Keywords>0x80000000000000</Keywords>
<TimeCreated SystemTime="2010-09-23T09:29:28.000000000Z" />
<EventRecordID>55259</EventRecordID>
<Channel>Application</Channel>
<Computer>ExDB01.testing.local</Computer>
<Security />
</System>
<EventData>
<Data>Primary (48706c9c-ad51-40d6-98b1-eb11039385e5)</Data>
<Data>/To-Do-Search</Data>
<Data>MapiExceptionInvalidEntryId: Unable to SetSearchCriteria. (hr=0x80040107, ec=-2147221241)
Diagnostic context:
Lid: 26926
Lid: 22830 StoreEc: 0x80040107
Lid: 32558
Lid: 18222 StoreEc: 0x80040107
Lid: 26414
Lid: 19246 StoreEc: 0x80040107
Lid: 18094
Lid: 27310 StoreEc: 0x80040107
Lid: 32382
Lid: 31358 StoreEc: 0x80040107
Lid: 16510
Lid: 31358 StoreEc: 0x80040107
Lid: 16510
Lid: 31358 StoreEc: 0x80040107
Lid: 26750
Lid: 22654 StoreEc: 0x80040107
Lid: 22161
Lid: 19089 StoreEc: 0x80040107
Lid: 18065
Lid: 26257 StoreEc: 0x80040107</Data>
<Data>--------
Operation: IDestinationFolder.SetSearchCriteria
OperationSide: Target
Primary (48706c9c-ad51-40d6-98b1-eb11039385e5)
Restriction: Restriction: AND[AND[PROPERTY[ptag:ParentEntryId, NotEqual, val:[Tag:ParentEntryId, Value:cb = 22, lpb = 0001020000000001A268000000000000000000000000]]; PROPERTY[ptag:ParentEntryId, NotEqual, val:[Tag:ParentEntryId, Value:cb = 22, lpb = 00010A00000005B10002000000000000000000000000]]; PROPERTY[ptag:ParentEntryId, NotEqual, val:[Tag:ParentEntryId, Value:cb = 22, lpb = 0001020000000007DC6E000000000000000000000000]]; PROPERTY[ptag:ParentEntryId, NotEqual, val:[Tag:ParentEntryId, Value:cb = 22, lpb = 0001020000000001A266000000000000000000000000]]; PROPERTY[ptag:ParentEntryId, NotEqual, val:[Tag:ParentEntryId, Value:cb = 22, lpb = 00010400000002548DCA000000000000000000000000]]; PROPERTY[ptag:ParentEntryId, NotEqual, val:[Tag:ParentEntryId, Value:cb = 22, lpb = 00010400000002548DCB000000000000000000000000]]; PROPERTY[ptag:ParentEntryId, NotEqual, val:[Tag:ParentEntryId, Value:cb = 22, lpb = 00010400000002548DCC000000000000000000000000]]; PROPERTY[ptag:ParentEntryId, NotEqual, val:[Tag:ParentEntryId, Value:cb = 22, lpb = 00010400000002548DC9000000000000000000000000]]]; AND[EXIST[ptag:237764866]; BITMASK[ptag:MessageFlags, EqualToZero, mask:0xC]]]
EntryIDs: [[len=46, data=0000000020EAD2782070D3118CB000105AF14FD70100712D5DEA935BD3118CA900105AF14FD700000001A2620000]]
Flags: Restart, Recursive, NonContentIndexed, FailOnForeignEID
--------
Search folder: '/To-Do-Search', entryId [len=46, data=0000000020EAD2782070D3118CB000105AF14FD701008A7E0BD32E921449A8B66F31569AEBF10000002E58E60000], parentId [len=46, data=0000000020EAD2782070D3118CB000105AF14FD70100712D5DEA935BD3118CA900105AF14FD700000001A2610000]</Data>
</EventData>
</Event>
Als ersten Schritt wurde dem „move request“ die Option „Skip the corrupted messages“ mit dem Wert von 5 mitgegeben. In der Regel waren im Durchschnitt nur 3 korrupte Objekte betroffen. Dadurch wurden die Mailboxen erfolgreich übertragen.
Bei näherer Untersuchung stellte ich fest, dass der Fehler nur bei Nutzern auftritt, die ihr Outlook im „Cache Mode“ betreiben und die Aufgabenliste (To-Do Bar) verwenden. Wenn der „Cache Mode“ bei den betroffenen Nutzern in den Outlook Optionen abgeschalten wird, ist die Aufgabenliste leer bzw. wird nicht angezeigt. Wenn der „move-Mailbox“ Prozess bei 10% abbricht, so handelt es sich bei den korrupten Objekten um Standard Ordner oder Such-Ordner, wie in diesem Fall beschrieben. Sollte der Prozess bei einer höheren Prozentzahl abbrechen, so handelt es sich um individuelle korrupte Objekte.
Das Problem kann auf zwei Arten gelöst werden, entweder mit Outlook Commandline-Switches oder mit dem Tool „MFCMAPI„.
Die Outlook Variantre:
Bei den meisten Nutzern reichte es aus Outlook mit folgenden „Switches“ zu starten, um die korrupten Objekte zu bereinigen:
outlook.exe /cleanfinders
Bei einige Nutzern reichte das leide nicht aus um alle korrupten Objekte zu bereinigen, dazu wurde Outlook dann mit folgenden „Switches“ aufgerufen:
outlook.exe /cleanreminders /resettodobar
Damit wurden nahe zu alle Mailboxen bereinigt und konnten dann problemlos verschoben werden. Bei den ganz hartnäckigen Fällen half dann nur noch „MFCMAPI„.
Die MFCMAPI Variante:
Bei den hartnäckigen Fällen verbindet man sich mit MFCMAPI und löscht den “Reminders” oder “Tracked Mail Processing” Ordner (kein permanente Löschung vornehmen!). Danach konnten alle Nutzer verschoben werden, ohne dass weitere korrupte Objekte gemeldet wurden.
Sollte es darüber hinaus weitere Probleme mit fehlenden Aufgabenbereichen (To-Do Bar) geben, dann öffnet man die Mailbox mit MFCMAPI und löscht (permanent/unrecoverable) den Ordner „To-Do Search“ aus dem Root der Mailbox.
Öffentliche Ordner können nur innerhalb einer Organisation repliziert werden. Für die Verbindung zwischen Organisationen gibt es aber auch Hilfsmittel. (Siehe Verbinden von Organisationen ). Über das Programm InterOrg Replication Tool ist es möglich, den Inhalt von öffentlichen Ordnern einer Organisation in eine andere Organisation zu replizieren. Das funktioniert auch mit Frei/Belegt-Zeiten. Der Trick daran ist, dass Outlook bei der Einladung eines Kontakts ebenfalls in dem Systemordner des eigenen Standorts nach einen Frei/Belegt-Datensatz sucht. Allerdings nutzt Outlook hierzu nicht den LegacyExchangeDN , sondern einfach die SMTP-Adresse. Sobald also ein Elemente im Ordner liegt, dessen Betreff der SMTP-Adresse entspricht, versucht Outlook diese Informationen in einer Terminvereinbarung mit anzuzeigen.