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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >> *Sent: *28 May 2020 19:15 >> *To: *Matthew Loraditch <[email protected]> >> *Cc: *[email protected] >> *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 < >> [email protected]> 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: *[email protected]* >> <[email protected]> >> >> [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 >> [email protected] >> https://puck.nether.net/mailman/listinfo/cisco-voip >> >> >> _______________________________________________ >> cisco-voip mailing list >> [email protected] >> https://puck.nether.net/mailman/listinfo/cisco-voip >> >
_______________________________________________ cisco-voip mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-voip
