I’ve recently experienced several different cases where replication between Exchange 2003 to 2007 was not working 100%. Much of the content had come over but some was not.  This blog talks about some of the steps that we took to isolate and resolve this.

NOTE: Before you go any further, be sure to read the Public Folder Replication Troubleshooting blog: http://msexchangeteam.com/archive/2008/01/10/447843.aspx

IS THE PROBLEM REAL

Checking ESM may show you that the size and total items may be mismatched from a Exchange 2003 and 2007 server. If so, determine which folders are experiencing this and what type of content they hold. Log onto the Public Folder store using Outlook or MFCMapi to spot check that the content is in fact out-of-sync with each other.

Know that Public Folder calendars may not be 100% equal from 1 server to another. This is because when you use OWA or any CDO application to access a calendar Public Folder, an instance of recurring items is created and stored within the Public Folder. While this instance is not visible in Outlook, it does add to the item count on the public folder, as seen in ESM. Additionally, those instances are not replicated between public folders so it is possible that a calendar PF on ServerX has many more items listed than ServerY. And they might have their content in-sync.

TRY THE BASICS

Once you have identified the Public Folder(s) that are not in sync, do some of the basic steps to force replication:

NOTE: See KB 842273 How to troubleshoot public folder replication problems in Exchange 2000 Server and in Exchange Server 2003

1. Turn up MSExchangeIS\Public Diagnostic Logging related to Replication on the source and target Exchange servers
2. Enable Messaging Tracking on both source and target servers
3. Within ESM, right click on the Organization object and make sure that Public Folder replication is not paused.
4. Ensure that the Exchange 2007 Public Folder store is listed as a Public Folder replica and that the store is mounted
5. Check the Exchange 2007 server Public Folder Administration tool (toolbox) and verify that the hierarchy has replicated to the server. Hierarchy before data!
6. Check the configuration of the antivirus software – ensure that it does not include Public Folder messages (DoNotScanIPMReplicationMessages)
7. Add new content to the source public folder and ensure that the new content has replicated over to the target server
8. Use PFDavAdmin against the source server to remove item-level permissions
9. Right click the problem folder and select Resend Changes. Send all changes over the past 1000 days or so.
10. Review the application log on the source server to see if a replication message for that folder has left the source server.

If so, check the target server’s application log to see if a replication message came in. If there is no inbound application log message for replication, message track that message from the source server.

If not, search for warnings and errors related to PF Replication.

NEXT STEPS

At this point, you should have isolated which folders work and which do not. Also, you know if the message is leaving the source server or not and if the target server is accepting the message or not. Also, message tracking would tell you if an NDR was returned (ex: 554 5.6.0 STOREDRV.Deliver.Exception propertyValidationException) .

An NDR may indicate that there is an incorrect property value set (or missing) on the Public Folder. To find that property, try:

1. On the Hub Transport Server, enabled ContentConversionTracing & PiplineTracing
2. Modify some items in the source Public Folder
3. Search the content conversion file for Exception. Here are 3 different issues that we experienced:

ERROR 1: Microsoft.Exchange.Data.Storage.PropertyValidationException: Property validation failed. Property = [{00020329-0000-0000-c000-000000000046}:'Keywords'] Categories 

Error = Element 0 in the multivalue property is invalid..

CAUSE: Content Conversion logging showed us that there was an issue with the Categories field on a Public Folder. So we opened Outlook against the source folder and viewed the content by Category (Views > Current Views). What we found was that some categories had an invalid character listed, such as a @, comma, or space. We edited those objects and removed the invalid character from the category field and then replication worked properly for those objects.

ERROR 2: Microsoft.Exchange.Data.Storage.PropertyValidationException: Property validation failed. Property = [{00062004-0000-0000-c000-000000000046}:0x8092] Email2AddrType

Error = Email2AddrType is too long: maximum length is 9, actual length is 25.

CAUSE: Here we see that Email2AddrType is the problem. This particular folder was a Contacts folder. What we found was that some of the contacts had invalid addresses listed. We modified those addresses and replication completed properly for those objects.

ERROR 3: FAIL 554 5.6.0 STOREDRV.Deliver.Exception.ObjectValidation Failed to process message due to a permanent exception

Microsoft.Exchange.Data.Storage.ObjectValidationException: The object is invalid and cannot be saved.

CAUSE: With this error, we were trying to replicate recurring appointments. Taking a closer look at those appointments, we realized that some did not have any end-date (EndTimeProperty) set. We edited the endtime of the meeting. In doing so, an update to the meeting was sent out to all of the attendees.

WHAT ELSE

If ContentConversion or Pipeline Tracing do not help, you could use the tracing features from the Exchange Troubleshooting Assistant (EXTRA) to potentially isolate the problem.

1. Start > Run > EXTRA
2. Select Trace Control from the Tasks
3. Select Manual Trace Tags
4. Select all types & select the following tags for the STORE component: tagPFReplHier, tagPFReplInbound, tagPFReplInit, TagAccessDenied, tagAccessDeniedDetails, tagDeliverMail, tagDispatchRpcCalls, tagDispatchRpcReturns, tagError, tagPFDLocalDelivery, & tagRpcIntError
5. Replicate PF content again and then stop tracing
6. Review the trace logs

This should get you closer to the problem…

Doug