Summary:

Depending on your Exchange configuration, you may need to set your CRM impersonated user's primary SMTP address to user@domain. This setting is applied on the Exchange server.

Symptoms:

On attempting to save a new Exchange integration in CRM 7.2, the setup fails on the second test.

The following HTTP 400 error is displayed in the ewaresystem.log:

Nov 21 2013 14:26:41.743 6804 5300 5 ERROR: checkExchangeUserEmail
 CODE: 0
 URL : http://crm-server/sdata/crmExchangeSyncEngine/crmExchange/-/$service/checkExchangeWebSiteAvailability?url_ews=https%3A%2F%2Fexchange-server%2Fews%2Fexchange.asmx&user_ews=crmuser&password_ews=%26HACPMNGEECFNKFMDJKAPGBECIHEGAENI&domain_ews=MYDOMAIN&crmuser=Admin
 MSG : <CheckExchangeResponse><errorMessage>com.sage.scrm.syncengine.exchange.ews.service.error.SageExchangeServiceException: javax.xml.ws.soap.SOAPFaultException: The request is invalid.</errorMessage><httpStatus>400</httpStatus></CheckExchangeResponse>

This HTTP request is used when attempting to resolve the impersonated user's mailbox on Exchange. The error code advises you to check the impersonated user's email address.

More detail regarding the error can be obtained by enabling CXF logging. This allows you to log all HTTP requests and responses sent by the CRM Exchange synch engine to the Exchange web services endpoint.

These logs can be enabled by amending the log4j.properties in \CRM\tomcat\webapps\crmExchangeSyncEngine\WEB-INF\.

On the following lines, change the word ERROR to DEBUG.

#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=DEBUG, 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=DEBUG, 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

The above is for illustrative purposes; you generally won't need to enable CXF logging in order to resolve this issue, but it will make clearer what the root cause of the issue is.

The following request and response are logged:

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Header>
    <RequestServerVersion xmlns:ns2="http://schemas.microsoft.com/exchange/services/2006/messages" xmlns="http://schemas.microsoft.com/exchange/services/2006/types" Version="Exchange2007_SP1" />
    </soap:Header>
    <soap:Body>
      <ns2:ResolveNames xmlns="http://schemas.microsoft.com/exchange/services/2006/types" xmlns:ns2="http://schemas.microsoft.com/exchange/services/2006/messages" ReturnFullContactData="false">
        <ns2:UnresolvedEntry
          crmuser@mydomain 
        </ns2:UnresolvedEntry>
      </ns2:ResolveNames>
    </soap:Body>
  </soap:Envelope>

From the above, it can be seen that CRM is sending a request to Exchange asking it if it can find a mailbox for crmuser@mydomain. UnresolvedEntry doesn't indicate an error in and of itself - it's used to inform Exchange that we would like to resolve a mailbox form the given SMTP address. Here’s the response from Exchange.

<?xml version="1.0" encoding="utf-8"?>
  <s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
    <s:Header>
      <h:ServerVersionInfo MajorVersion="15" MinorVersion="0" MajorBuildNumber="712" MinorBuildNumber="22" Version="V2_3" xmlns:h="http://schemas.microsoft.com/exchange/services/2006/types" xmlns="http://schemas.microsoft.com/exchange/services/2006/types" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/>
      </s:Header>
      <s:Body xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
        <m:ResolveNamesResponse xmlns:m="http://schemas.microsoft.com/exchange/services/2006/messages" xmlns:t="http://schemas.microsoft.com/exchange/services/2006/types">
          <m:ResponseMessages>
            <m:ResolveNamesResponseMessage ResponseClass="Error">
              <m:MessageText
                No results were found. 
              </m:MessageText>
              <m:ResponseCode
                ErrorNameResolutionNoResults
              </m:ResponseCode>
              <m:DescriptiveLinkKey>
                0
              </m:DescriptiveLinkKey>
            </m:ResolveNamesResponseMessage>
          </m:ResponseMessages>
        </m:ResolveNamesResponse>
      </s:Body>
    </s:Envelope>

This indicates that Exchange cannot resolve a mailbox for a user with the mailbox crmuser@mydomain.

Resolution:

Setting crmuser@mydomain to be the primary SMTP address for the impersonated user’s Exchange mailbox should resolve the issue. There should be no major issue with using user@domain as the primary address - no emails will be sent out directly from the impersonated user's mailbox, so the SMTP address used will not be visible to users and recipients.

This issue is resolved in v7.2e. As of that version, it is possible to use secondary SMTP addresses to identify the CRM impersonated user's mailbox.