[cisco-voip] UCCX 11.6 HA LAN to WAN

[Michael Nickolich]

Thank you guys for all your feedback! This exactly what we were looking for
with this move.Based on the responses, we'll need to do the HA WAN and new
hostname. Current config has the device pool as UCCX_ABC, so the agents
would eventually fail-over to CUCM Sub C in DC2. CUCM Sub A and B, as well
as CUCM Pub are in DC1 and will be down for a majority of the day as they
upgrade power in DC1. Honestly, not sure that I prefer that they have to
prefer CUCM Sub in DC2, but I was worried about the agents ability to
authenticate with their local end user accounts.

Could we just keep HA LAN and update the UCCX Unified CM Configuration to
include Sub C in DC2? Current AXL Service Providers only list the CUCM Pub,
and JTAPI and RmCm both have CUCM Sub A and B in DC1. Could I just add Sub
C as a secondary AXL Service Provider and then swap out one of the Subs
listed in DC1 to Sub C in DC2 for both JTAPI and RmCm?


On Fri, Aug 30, 2019 at 1:19 PM Brian Meade <bmeade90 at vt.edu> wrote:

> Yea, I think the process would work fine with new hostname.  I'm wondering
> if deleting a sub and re-adding/rebuilding with same hostname as WAN causes
> some issues which needed that cleanup script.
>
> On Fri, Aug 30, 2019 at 11:06 AM Anthony Holloway <
> avholloway+cisco-voip at gmail.com> wrote:
>
>> You can't convert the model from LAN to WAN, per se.  You basically just
>> destroy your HA by deleting the Sub from the Pub GUI.  Then delete your Sub
>> VM.  Then, you rebuild the whole Sub integration from scratch, as if it was
>> new.
>>
>> On Fri, Aug 30, 2019 at 9:55 AM Brian Meade <bmeade90 at vt.edu> wrote:
>>
>>> HA over WAN allows each server to have different configurations for the
>>> Unified CM connection as well as your call control groups.  So you could
>>> have the subscriber connect to a local CUCM subscriber and have different
>>> device pools for those CTI groups to use that local subscriber as well.
>>>
>>> I've definitely seen some bugs with HA over WAN in older versions but it
>>> should be pretty stable now.
>>>
>>> I've never tried to convert an existing subscriber from LAN to WAN.
>>> There may indeed be some database references that don't get fully cleaned
>>> up when deleting the subscriber from the publisher.  You would probably
>>> have better luck using a different hostname for the new subscriber.
>>>
>>> On Fri, Aug 30, 2019 at 10:45 AM Michael Nickolich <
>>> michael.nickolich at gmail.com> wrote:
>>>
>>>> Hello all,
>>>>
>>>> We are looking to geographical separate our HA UCCX 11.6.1 nodes, which
>>>> are currently in "data center 1". We will be installing the UCCX Sub at our
>>>> other data center across campus, which is connected by 10Gb fiber. "Data
>>>> Center 2" already has two UCM Subscribers and this is where the UCCX Sub
>>>> will reside. My question is when we install the new Sub, will we select HA
>>>> over LAN or HA over WAN? TAC said it needs to be HA over WAN as the Pub and
>>>> Sub will be on different networks. TAC also said they would need to have
>>>> root access to delete the Sub from the Pub and delete any traces of the old
>>>> Sub. Then add the Sub back to the Pub. The documentation does not mention
>>>> anything about contacting TAC to gain root access for Switching Network
>>>> Deployment from LAN to WAN. Just wondering if their documentation needs
>>>> updated or if the TAC engineer misspoke.
>>>>
>>>> We will be keeping the same hostname for the server. Going to have our
>>>> Sys Admins to lower the TTL on the original record prior to making these
>>>> changes. Once we remove the Sub, have the Sys Admin update the A and PTR
>>>> record to point to the new IP and set TTL back to the default. Then verify
>>>> DNS resolution to the new IP.
>>>> Then install the new UCCX Sub. Still not sure HA over LAN or WAN.
>>>> Then update AXL, JTAPI, and RmCM to include one UCM Sub from data
>>>> center 2 in case there is a total outage in data center 1. Currently AXL
>>>> only has the UCM Pub.
>>>>
>>>> Any guidance on any gotchas would be greatly appreciated.
>>>>
>>>> Thanks,
>>>>
>>>> _______________________________________________
>>>> cisco-voip mailing list
>>>> cisco-voip at puck.nether.net
>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>
>>> _______________________________________________
>>> 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/20190903/6483ec85/attachment.htm>