[cisco-voip] CUCM DNS/CTL configuration - follow-up

[Brian Meade]

I've seen it work most of the time just adding the CallManager-trust.  On
one occasion, I did have to restart the CallManager service for it to take
affect.  Make sure to upload to every node.

You also shouldn't see any phone reboots for adding a CallManager-trust.
That would only be in the case you end up having to restart the CallManager
service.

On Thu, May 28, 2015 at 10:37 AM, Ed Leatherman <ealeatherman at gmail.com>
wrote:

> It's not a tomcat-trust cert though, the docs (and expressway) say it
> needs to go in the callmanager-trust
>
> On Thu, May 28, 2015 at 10:25 AM, Charles Goldsmith <wokka at justfamily.org>
> wrote:
>
>> Just restart Tomcat
>>
>> On Thu, May 28, 2015 at 8:21 AM, Ed Leatherman <ealeatherman at gmail.com>
>> wrote:
>>
>>> Good morning!
>>>
>>> Cert related question - think I know the answer but I dont see it
>>> explicitly stated so figured I'd ask.
>>>
>>> I need to add the CA cert for my expressway-C to call manager as a
>>> callmanager-trust cert - do I need to reboot the call manager service for
>>> this to take effect? No forced phone reboots since this is just a trust
>>> cert, correct? I think the answer is no and no phone reboots.
>>>
>>> Thanks!
>>>
>>> Ed
>>>
>>>
>>>
>>>
>>> On Mon, May 18, 2015 at 10:46 AM, Brian Meade <bmeade90 at vt.edu> wrote:
>>>
>>>> Ed,
>>>>
>>>> All phones re-registering is expected behavior for when any
>>>> CallManager, CAPF, or TVS certificate on any node in the cluster is
>>>> regenerated.  This is to allow phones to download an updated ITL before
>>>> another certificate change is made.  This is also the same reason all
>>>> phones re-register when adding a new node to a cluster.
>>>>
>>>> Tomcat-trusts usually automatically get updated via the Certificate
>>>> Change Notification process.  There has been a few times I've seen
>>>> conflicts that caused this not to work right though.
>>>>
>>>> Brian
>>>>
>>>> On Sun, May 17, 2015 at 10:06 AM, Ed Leatherman <ealeatherman at gmail.com
>>>> > wrote:
>>>>
>>>>> Good morning,
>>>>>
>>>>> This morning I enabled DNS servers, domain name on our CUCM Cluster,
>>>>> which involved regenerating all the certs on the cluster. Note I have
>>>>> cluster mixed mode. Everything appears to have gone smoothly, but I had 2
>>>>> odd things happen that I did not expect.. tossing them out here in case it
>>>>> helps someone else, or if someone has commentary on "why" :)
>>>>>
>>>>> Reference: CUCM v9.1, mixed mode, never had dns servers or domain set
>>>>> before.
>>>>>
>>>>> - After setting primary, secondary DNS and domain name, and the
>>>>> subsequent reboot on each node ALL my phones on the cluster restarted or at
>>>>> least re-registered each time, even for phones that do not use that node as
>>>>> a CM. Is this CM process restarting everywhere each time or ? I didnt think
>>>>> to check runtime on the CM process while I was working.
>>>>>
>>>>> - I expected to have to import tomcat certificates back and forth to
>>>>> the publisher at each node once the certs were regenerated, as this was
>>>>> necessary in the past. Apparently now they automagically download them from
>>>>> each other? I went in to do it and the tomcat-trust was already there with
>>>>> the new domain name.
>>>>>
>>>>> Cheers!
>>>>>
>>>>> Ed
>>>>>
>>>>> --
>>>>> Ed Leatherman
>>>>>
>>>>> _______________________________________________
>>>>> cisco-voip mailing list
>>>>> cisco-voip at puck.nether.net
>>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>>
>>>>>
>>>>
>>>
>>>
>>> --
>>> Ed Leatherman
>>>
>>> _______________________________________________
>>> cisco-voip mailing list
>>> cisco-voip at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>
>>>
>>
>
>
> --
> Ed Leatherman
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20150528/06b0ca09/attachment.html>