MapiExceptionNotFound during content replication

Today, I want to talk about another public folder replication problem we see repeatedly. Aren’t you glad PF replication is gone in Exchange 2013?

This is one of the rarer public folder replication issues that we see, and it’s caused by the attributes on the database. Actually, a database in this state sometimes causes a problem and sometimes does not, and I want to explain why that is.

The way this problem surfaces is that you see an event 3085 stating that outgoing replication failed with error 0x8004010f. If you try something like Update Content, you’ll get some error output with a diagnostic context that looks like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

Error:
Cannot start content replication against public folder '\SomeFolder' on public folder database 'PFDB1'.

MapiExceptionNotFound: StartContentReplication failed. (hr=0x8004010f, ec=-2147221233)
Diagnostic context:
    Lid: 1494    ---- Remote Context Beg ----
    Lid: 19149   Error: 0x0
    Lid: 25805   Error: 0x0
    Lid: 11752   StoreEc: 0x8004010F
    Lid: 25260  
    Lid: 19149   Error: 0x0
    Lid: 25805   Error: 0x0
    Lid: 11752   StoreEc: 0x8004010F
    Lid: 25260  
    Lid: 19149   Error: 0x0
    Lid: 3010    StoreEc: 0x8004010F
    Lid: 3010    StoreEc: 0x8004010F
    Lid: 3650    StoreEc: 0x8004010F
    Lid: 3010    StoreEc: 0x8004010F
    Lid: 3010    StoreEc: 0x8004010F
    Lid: 3650    StoreEc: 0x8004010F
    Lid: 2492    StoreEc: 0x8004010F
    Lid: 2108    StoreEc: 0x8004010F
    Lid: 18128   StoreEc: 0x8004010F
    Lid: 18536   StoreEc: 0x8004010F
    Lid: 18544   StoreEc: 0x8004010F
    Lid: 18560   StoreEc: 0x8004010F
    Lid: 18740   StoreEc: 0x8004010F
    Lid: 1267    StoreEc: 0x8004010F
    Lid: 33819   StoreEc: 0x8004010F
    Lid: 27225   StoreEc: 0x8004010F
    Lid: 1750    ---- Remote Context End ----
    Lid: 26322   StoreEc: 0x8004010F

There are many problems that could cause some diagnostic output that looks similar to this. For this particular problem the error must be MapiExceptionNotFound, and the sequence of Lids will usually be pretty close to what you see here.

This error occurs when the replica list on a public folder contains the GUID of a public folder database which does not have an msExchOwningPFTree value. It’s easy to find a database in this state with an ldifde command to dump the properties of any public folder database objects where this value is not set:

1

ldifde -d "CN=Configuration,DC=contoso,DC=com" -r "(&(objectClass=msExchPublicMDB)(!(msExchOwningPFTree=*)))" -f unlinkedpfdb.txt

To fix the problem, you can either:

1. Delete the folder, if you can figure out which one it is.
2. Populate the msExchOwningPFTree value.
3. Delete the database in question from the Active Directory.

Option 1 is usually not desirable, but I included it to illustrate the fact that a database in this state only causes a problem if existing folders ever had replicas on it. Keep in mind that the replica list you see in the management tools only shows you the current active replicas. The internal replica list tracks every replica that has ever existed, forever. Even if you remove all replicas from the database in question using the management tools, the GUID of that database is still present in the internal replica list, and it always will be. Thus, you cannot unlink a database from the hierarchy if any existing folder has ever had replicas on it - at least, not without breaking replication.

This is important, because certain third-party software will purposely keep public folder databases around that are not linked to the hierarchy. And that works fine, as long as they don’t have replicas, and never did.

Option 2 is the proper approach to fixing this situation if the database is still alive. Perhaps someone manually cleared the msExchOwningPFTree while troubleshooting or trying to affect the routing of emails to public folders. Just set the value to contain the DN of the hierarchy object. You can check your other PF databases to see what it should look like, as they should all have the same value. A few minutes after setting the value, replication should start working again.

If the database has been decommissioned, perhaps ungracefully, and it no longer exists, then you can go with option 3 and simply delete the Active Directory object for the database using ADSI Edit. When the GUID in the replica list does not resolve to an object in the AD, that’s fine - that’s the normal state for a folder that once had replicas on databases that aren’t around anymore, so it doesn’t cause any problem.