SOAP-CallRecord Service restart every 10 minutes

[Christopher Gavula]

Just upgraded an 8.5(1) CUCM to 10.5(1) and now seeing SOAP-CallRecord Service restart every 10 minutes. 

Anyone have any idea what might be causing it?  DB replication appears to be good. User's aren't reporting any calling difficulties.

[kylepetree]

Sorry to piggy back Christopher, but I'm seeing the same thing after upgrade from 9.1.1 to 9.1.2 and install of a Device Pack to support 78xx phones.

[Hard_Boiled_Greg]

Hi Christopher,

Did you ever get a resolution to the SOAP-CallRecord Service restarting issue? I just upgraded several clusters to 10.5(1) and am seeing the same issue on all of them.

Regards,

Greg

[keglass]

Greg,

I recommend you also post this to the Cisco Support Community (https://supportforums.cisco.com/index.jspa) for additional information and feedback.  If you suspect this could be a bug, another option is to open a ticket with the Cisco Technical Assistance Center (www.cisco.com/go/support) to get expert debugging advice and help.

Kelli Glass

Moderator for Cisco Customer Communities

[tom golan]

Hi guys,

Did you manage to solve this issue ?

Thanks,

Tom.

[Hard_Boiled_Greg]

Hi all,

I did open a TAC SR, and we found the root cause. The issue stemmed from an expired tomcat.pem certificate on each of the clusters where we were having the issue. Once I updated the tomcat.pem certificate I was able to start the SOAP - CDRonDemand service and the SOAP-CallRecord errors went away. I'm looking clean now.

[Kevin Spicer]

I had the same problem following an upgrade from 9.1.2 to 10.5, but with a different cause / resolution.  Thought I would add the solution here in case it helps others.

In our case the problem was caused by the CUCService application user not being a member of the 'Standard CCM Admin Users' group.  Addint the user to the group and restarting the service cleared the problem.

The TAC engineer also suggested setting the CUCService account to the same password as the application administrator account (i.e. the account created at install time for login to CCM) and restarting the service.  Changing the password wasn't necesary in our case.