[cisco-voip] [External] Re: Migration from CUCM/UCXN/UCCX 8.5 to 12.5

Thu May 28 14:45:58 EDT 2020

Correct.  Today, it's basically the standard to involve DNS in your
deployment.  However, there's always exceptions to the rule.

On Thu, May 28, 2020 at 1:35 PM Hunter Fuller <hf0002 at uah.edu> wrote:

> I swear, really, that I'm not trying to stir anything up here.
>
> But is there any reason to turn up a new cluster with IPs?? You have to
> use FQDNs for at least some stuff (Jabber and web portal related stuff in
> particular)...
>
> I promise I'm not trying to start something.
>
> --
> Hunter Fuller (they)
> Router Jockey
> VBH Annex B-5
> +1 256 824 5331
>
> Office of Information Technology
> The University of Alabama in Huntsville
> Network Engineering
>
>
> On Thu, May 28, 2020 at 1:28 PM James B <james.buchanan2 at gmail.com> wrote:
>
>> I was thinking of the community configuration approach Anthony suggested
>> and was thinking of the debates we’d have if we did that:
>>
>>
>>
>>    1. Do you use “_PT”, “PT_”, or just the site name? Same for “CSS”,
>>    “LOC”, and the ever-debated “RGN” or “REG”?.
>>    2. FQDN or IP addresses?
>>    3. Do all the media resources go into a single MRG or not?
>>    4. Do we click “Run on all Nodes” for route lists and trunks or not?
>>    5. MGCP, SIP, or H323 (if using PRIs)?
>>    6. Can UCCX have upper-case hostnames or not?
>>
>>
>>
>> The debates would take us so long, version 14.0 would be out, and then
>> we’d have to debate about whether a “.0” versoin is stable or not or should
>> we wait for “.5”? Still, could be fun!
>>
>>
>>
>>
>>
>>
>>
>> *From: *Anthony Holloway <avholloway+cisco-voip at gmail.com>
>> *Sent: *28 May 2020 19:15
>> *To: *Matthew Loraditch <MLoraditch at heliontechnologies.com>
>> *Cc: *cisco-voip at puck.nether.net
>> *Subject: *Re: [cisco-voip] Migration from CUCM/UCXN/UCCX 8.5 to 12.5
>>
>>
>>
>> Keep in mind that PCD network migrations, while awesome for CUCM, do not
>> work for other products.
>>
>>
>>
>> Typically with a project like this, you'll likely have a different
>> approach for each app, and not a one size fits all solution.
>>
>>
>>
>> With the app upgrades, you will also have to change OVA sizes (or want to
>> in some cases), and at that point, it might be better to install fresh, and
>> use tools like COBRAS, BAT, AXL, ADMIN API, stare & compare, etc. to get
>> data exported/imported from old to new.
>>
>>
>>
>> Or like Kent said, tell yourself it's a toshiba system, and treat it like
>> a greenfield.
>>
>>
>>
>> On Thu, May 28, 2020 at 11:26 AM Matthew Loraditch <
>> MLoraditch at heliontechnologies.com> wrote:
>>
>> Here’s a fun one. We have taken over support of these ancient servers
>> hosted on Esxi 4.1 on UCS-C200-M2s!
>>
>>
>>
>> Exact Versions are:
>>
>> 8.5 SU2 for CUCM/UCXN
>>
>> 8.5 FCS for UCCX
>>
>>
>>
>> Each  is a pair of servers.
>>
>>
>>
>> Have new M5s and flex licensing… need to get to 12.5..  8.5 docs are dead
>> for CUCM/UCXN and 8 and 9 docs are dead for UCCX. ISOs I may need are not
>> available publicly.
>>
>>
>>
>> Also fun wrinkle the new host are across the WAN and for many logistical
>> reasons are staying there. The migration to the new hosts will have to be
>> via DRS or maybe PCD somehow? Not sure if the bandwidth available to get
>> data across will be fast enough to finish in the allotted time period. My
>> plan was a change freeze window and copy/restore the backups and then
>> activate the new servers and move the subnet to the new location.
>>
>>
>>
>> As best I can tell I need to get UCCX to SU4 of 8.5.1 then I can go to
>> 10.6 SU3 and then to 12x (with the fun of two CAD upgrades and then a
>> migration to Finesse!)
>>
>>
>>
>> For CUCM/UCXN I need to go to 8.6 anything and then I can go to 11.5 and
>> then to 12x
>>
>>
>>
>> I think my plan is to do the upgrades to the interim versions on the old
>> hosts then migrate to the new and then finish the upgrades. The old hosts
>> will need ESXi upgrades to an interim version.
>>
>>
>>
>> Anyone have thoughts on what they would do here? This is partially
>> depending on TAC being able to provide me the ISOs I will need, but I
>> presume there is an archive.
>>
>>
>>
>> In theory some sort of PCD migration is also an option, but I’ve never
>> done one and not sure how it could handle the subnet situation that will
>> have to exist.
>>
>>
>>
>> Welcome to my fun life!
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *Matthew Loraditch***
>>
>> *Sr. Network Engineer*
>>
>> p: *443.541.1518* <443.541.1518>
>>
>> w: *www.heliontechnologies.com* <http://www.heliontechnologies.com/>
>>
>>  |
>>
>> e: *MLoraditch at heliontechnologies.com*
>> <MLoraditch at heliontechnologies.com>
>>
>> [image: Helion Technologies] <http://www.heliontechnologies.com/>
>>
>> [image: Facebook] <https://facebook.com/heliontech>
>>
>> [image: Twitter] <https://twitter.com/heliontech>
>>
>> [image: LinkedIn] <https://www.linkedin.com/company/helion-technologies>
>>
>> _______________________________________________
>> 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/20200528/55994af1/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 69B9A58CE8224BBA9F198FF959ECAC52.png
Type: image/png
Size: 5500 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20200528/55994af1/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image029668.png
Type: image/png
Size: 444 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20200528/55994af1/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image808092.png
Type: image/png
Size: 561 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20200528/55994af1/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image983202.png
Type: image/png
Size: 431 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20200528/55994af1/attachment-0003.png>