Exchange sync not working after update to 7.3 SP2

Hi

After upgrading to Sp2 on 7.3 the exchange sync at my client stopped working, I can query the xml through the browser but the log keeps giving me status= 500

See below entries from log:

2016-05-12/06:34:38.442/CAT [Task Scheduler thread] DEBUG com.sage.scrm.syncengine.core.context.AppContext.init
2016-05-12/06:34:38.442/CAT [Task Scheduler thread] DEBUG com.sage.scrm.syncengine.core.context.AppContext.init
2016-05-12/06:34:38.444/CAT [Task Scheduler thread] INFO com.sage.scrm.syncengine.exchange.configuration.SCRMWebServiceConfigurationReader.retrieveConfiguration About to get configuration from CRM: GEOCOLOCRM01/.../getSyncEngineConfiguration
2016-05-12/06:34:39.465/CAT [Task Scheduler thread] ERROR com.sage.scrm.syncengine.exchange.configuration.SCRMWebServiceConfigurationReader.retrieveConfiguration com.sage.crm.httpconsumer.error.SageHttpConsumerException: GET failed on GEOCOLOCRM01/.../getSyncEngineConfiguration: status=500

Any ideas where to look, I reinstalled the programs and iis aliases. The client is really dependand on the syncs for their external staff's appointments.

  • 0

    Hi Abri,

    I posted the below answer on another forum post that had a similar issue. See below:

    "I've seen this happen when upgrading some of my clients with Exchange Integration. What happens in some cases is there's an extra space in the SQL table custom_tables that defines what prefix to use for a table. So when CRM is trying to reference an Exchange Integration table for example, it's trying to pull " Ecng _ColumnName" instead of "Ecng_ColumnName".

    The way to fix that is to run a SQL query to trim the spaces from the prefix on both sides, and that should resolve the issue. As always, make sure you back up your SQL database prior to running any queries - better safe than sorry."

    Hopefully that helps... 1.5 months later, but hopefully this has been resolved.

  • 0

    We have faced similar issue and the problem is under analysis at the development team.

    Last investigation where around the impersonated exchange user login name that had special characters.

    Issue was reproduced by the dev support team and not when using a simple user name (for instance : AdminCRMExchange" instead of "Admin_CRM-Exchange")

    Don't know if it solved the issue yet but I'll let you know