Hello,

did someone read my post ?

I will bring this to the attention of my colleagues.

Hi,

I worked on the case raised to us regarding the duplicates issue back in March and April (the one that might have been caused by the EcngIntegration record having been updated directly via Management Studio). This was closed in May, and we received notice that the issue had been resolved as a result of recreating the integration. The case reference for this was 0-163851.

I don't see any case that has been logged with us by yourself regarding Exchange phone numbers - if you have the reference there I can look it up and see what happened to it.

We don't store separate details regarding the integration in the Exchange mailboxes. I think that some of the confusion here comes from how Exchange might be handling phone numbers that have been entered, and also unanswered questions regarding whether these phone numbers have been updated by a 3rd-party integration (such as the iPhone).

CRM and Exchange both have separate fields for phone country codes, area codes and the local phone number. These map directly to each other. Special conditions might exist in the following cases:

1: If CRM has been set to not synch phone country and area codes (it should still synch them if they're still present in the database regardless of whether this option is enabled or not).

2: If the contact's phone record has been edited directly though Outlook (a single field is displayed for editing here, unless you drill down to the phone record). If, in the case a phone number is entered in a single field, then Exchange/Outlook will attempt to format out the country and area codes automatically.

In you case, values have been entered in the phone country and local number fields - I would expect that these should always just map directly against each other on both sides of the integration, assuming that neither is updated. I would consider any other behaviour to be a bug.

It doesn't sound like the phone number has been updated by anything on the Exchange side of the Exchange integration, but this is not guaranteed. It's entirely possible that another application, (most likely using Exchange ActiveSync) has synchronised phone numbers. This may have applied its own formatting to the phone number. This sort of error is (distressingly) common, and can cause seemingly-random behaviour in the integration.

The best way of confirming where a change has been made is by inspecting the CRM Exchange synch engine CXF logs. These logs contain the detail of all XML messages sent back and forth between the CRM Exchange synch engine and the Exchange web services endpoint. You can enable these logs by doing the following:

1. Stop Tomcat.

2. Archive the existing CRM and Tomcat service logs.

3. In ..\CRM\tomcat\webapps\crmExchangeSyncEngine\WEB-INF\log4j.properties replace the word ERROR with the word DEBUG in the following sections:

#cxf logging

log4j.logger.org.apache.cxf=ERROR, cxfgeneral

log4j.appender.cxfgeneral=com.sage.scrm.scrmcommons.util.DateFormatFileAppender

log4j.appender.cxfgeneral.FileDateTimePattern=\yyyyMMdd\'cxf-general.log\'

log4j.appender.cxfgeneral.File=${log.dir}/Exchange Integration/cxf-general.log

log4j.appender.cxfgeneral.DatePattern=${roll.pattern.daily}

log4j.appender.cxfgeneral.append=true

log4j.appender.cxfgeneral.layout=org.apache.log4j.PatternLayout

log4j.appender.cxfgeneral.layout.ConversionPattern=%d{${datestamp}} [%t] %-5p %C.%M %m%n

log4j.appender.cxfgeneral.Encoding=UTF-8

#cxf logging inbound traffic

log4j.logger.org.apache.cxf.interceptor.LoggingInInterceptor=ERROR, ininterceptor

log4j.appender.ininterceptor=com.sage.scrm.scrmcommons.util.DateFormatFileAppender

log4j.appender.ininterceptor.FileDateTimePattern=\yyyyMMdd\'cxf-ininterceptor.log\'

log4j.appender.ininterceptor.File=${log.dir}/Exchange Integration/cxf-ininterceptor.log

log4j.appender.ininterceptor.DatePattern=${roll.pattern.daily}

log4j.appender.ininterceptor.append=true

log4j.appender.ininterceptor.layout=org.apache.log4j.PatternLayout

log4j.appender.ininterceptor.layout.ConversionPattern=%d{${datestamp}} [%t] %-5p %C.%M %m%n

log4j.appender.ininterceptor.Encoding=UTF-8

#cxf logging outbound traffic

log4j.logger.org.apache.cxf.interceptor.LoggingOutInterceptor=ERROR, outinterceptor

log4j.appender.outinterceptor=com.sage.scrm.scrmcommons.util.DateFormatFileAppender

log4j.appender.outinterceptor.FileDateTimePattern=\yyyyMMdd\'cxf-outinterceptor.log\'

log4j.appender.outinterceptor.File=${log.dir}/Exchange Integration/cxf-outinterceptor.log

log4j.appender.outinterceptor.DatePattern=${roll.pattern.daily}

log4j.appender.outinterceptor.append=true

log4j.appender.outinterceptor.layout=org.apache.log4j.PatternLayout

log4j.appender.outinterceptor.layout.ConversionPattern=%d{${datestamp}} [%t] %-5p %C.%M %m%n

log4j.appender.outinterceptor.Encoding=UTF-8

4. Start Tomcat.

5. Reproduce the issue.

6. Gather the logs and reverse the additional logging.

The CXF logs look intimidating, but they're actually fairly easy to read, so long as you have something to parse the XML for you. The requests in the OUT interceptor are the ones sent out by CRM, while the responses are contained in the IN interceptor. The request numbers in each file correspond to each other - request 5 in the CXF IN interceptor is Exchange's response to request 5 in the CXF OUT interceptor.

Enabling the additional logging, then reproducing the issue should allow you to see at what point the phone number gets modified, and on which side of the integration.

If you can't see a cause from the above, or if it's CRM that's updating the phone numbers, then please log a case, or ask you local support team to follow up with your existing case reference for this.

I hope this helps.

All the best,

Rob

Thank you Rob for your time.

The issue with phone numbers has only been registered in my French local support. Their own Request Nr was 40585957.

I will forward your recommendation to IT team of my client for investigation.