http://ciscounitytools.com/Applications/CxN/MessageShuttle/MessageShuttle.html
TAC supported even. On Oct 31, 2016 9:12 PM, "Lelio Fulgenzi" <[email protected]> wrote: > What is this message shuttle magic you soak of? > > Sent from my iPhone > > On Oct 31, 2016, at 5:37 PM, Ryan Huff <[email protected]> wrote: > > Plus +1 to Anthony > > Message shuttle is silly fast too as it is just doing file copies and not > going through the COBRAS overhead. > > 1.) COBRAS (or DRS) initially to get the subscriber / handler schema moved > over (keeping in mind what COBRAS will not replicate, i.e. restriction > tables ... etc) > > 2.) Message shuttle right before the switch to move content. > > This also saves backing up messages initially if using COBRAS (assuming > COBRAS is being used in a migration / upgrade capacity and not just a > backup), which makes that whole process a ton faster too. > > -Ryan > > On Oct 31, 2016, at 5:28 PM, Anthony Holloway < > [email protected]> wrote: > > Or Message Shuttle? > > On Mon, Oct 31, 2016 at 11:10 AM, Matthew Loraditch <MLoraditch@ > heliontechnologies.com> wrote: > >> COBRAS would work for that. >> >> >> >> Matthew G. Loraditch – CCNP-Voice, CCNA-R&S, CCDA >> Network Engineer >> Direct Voice: 443.541.1518 >> >> Facebook <https://www.facebook.com/heliontech?ref=hl> | Twitter >> <https://twitter.com/HelionTech> | LinkedIn >> <https://www.linkedin.com/company/helion-technologies?trk=top_nav_home> >> | G+ <https://plus.google.com/+Heliontechnologies/posts> >> >> >> >> *From:* cisco-voip [mailto:[email protected]] *On >> Behalf Of *Scott Voll >> *Sent:* Monday, October 31, 2016 12:08 PM >> *To:* Peter Slow <[email protected]> >> *Cc:* cisco voip <[email protected]> >> >> *Subject:* Re: [cisco-voip] Not supported I'm sure..... but what do you >> think? >> >> >> >> Our biggest problem in this situation would be VM. if we restore from a >> backup on Monday in a Dark Network and switch over a weekend, is there a >> way to grab newer Voicemails to put on the "new" (upgraded) UC at the time >> of the switch? >> >> >> >> Scott >> >> >> >> >> >> On Sat, Oct 29, 2016 at 2:03 PM, Peter Slow <[email protected]> wrote: >> >> Hey guys. At a Co. I was working at with a megacluster, we took backups >> of the production cluster, and restored to a newly installed cluster on a >> "dark" net, and I NAT'd all the VMs so they could run and be upgraded >> separately and rebooted and tested with a few phones on a private network. >> Then I used some VMware Power CLI scripts to cut over each datacenter in a >> few seconds... ECATS was involved as well - there is a little bit of a >> precedent, though I recognize that we tailored that specifically for the >> customer's environment, and it might not work as well in some others. >> >> It should also be noted that the NEW (and subsequently upgraded, and >> switched into production) VMs were built using the actual TAC supported >> install process, as opposed to being cloned. The fact that the megacluster >> had 21 servers in basically equated to "not enough time to roll back before >> monday" for a number of reasons, an issue this upgrade & cutover method >> alleviated. I think it was an 8.6 to 9 upgrade. Because of some block level >> stuff, sine VMware wasn't supported (IIRC) in the starting version, after >> the upgrade of the 2nd set (referred to as "new" earlier) we took another >> back up and restored to *another* cluster, a set of newly installed 9.x VMs >> in *another* "dark" net. >> >> >> >> BE CAREFUL IF YOU DO THIS >> >> I did 5 production clusters this way - Having two to three sets of >> identical servers, with identical IPs WILL get confusing, i don't care how >> smart you are. >> >> Use login banners saying which cluster this server is in. It's annoying >> but apply them to each node so you are forced to see and can confirm you're >> logging in to ccmadmin on to cluster 1, 2 or 3. Having the cluster built >> before cutover lets you do things like fix an issue with a sub, or rebuild >> a node as many times as you want when/if an install fails. It's easy to get >> confused and blast a sub on the production cluster by accident at 3 pm on >> when you've got enough servers and have to admin one cluster, and build >> another, when you have multiple sets of identical things, and applying 100 >> banners is less annoying than the consequences of you or your customer >> screwing this up. >> >> When you need to restart/zap a UC VM that there are multiples of - >> require two people to look at it. Have your team lead or customer say "yes, >> that's the right one" before you click that button. >> >> Be very careful with naming things so you can safely script things in a >> low-risk fashion (E.g., so you can't reboot the wrong set of VMs while >> working on build #2) >> >> >> >> -Peter >> >> >> >> On Sat, Oct 29, 2016 at 1:28 PM, Ryan Huff <[email protected]> wrote: >> >> As it always has, IMO, it comes down to the nature and context of your >> client. For a true 8by5 SMB; large after hours maintenance windows >> generally aren't a problem as long as some sort of treatment is applied to >> the main ingress. >> >> >> >> However, the PS engagements I generally work with are medical/healthcare, >> specialized government and 24/7 private industries. If I would tell any of >> my clients: >> >> >> >> "starting at 9PM what we're gonna do is reboot the phone system and watch >> paint dry. In the case of an RU, we're gonna do that twice or thrice. Your >> phones will do a registration dance anywhere from 30 - 240 minutes." -I >> would get escorted out of their building. >> >> >> >> So as was mentioned earlier; we've all developed our 'ways' of shrinking >> the actual 'cut over window' to a matter of minutes. Those developments are >> rooted in the needs of our individual clients and spurred by the >> capabilities (some say limitations) of the software's upgrade functionality. >> >> >> >> Ideally, the inactive partition would have an externally addressable >> method where a unique/independent software version could be installed and >> run in tandem and the active partition had a 'publish' feature where when >> activated, would publish the active Informix schema to the inactive >> Informix schema (using a babble-fish style translator to comp the >> differences in schema versions). Then, your cut over is a matter of >> 'publish' and swap the partitions. >> >> >> >> All of that is possible, but would require a serious re-tool at the >> RedHat level. >> >> >> >> >> >> = Ryan = >> >> >> >> >> ------------------------------ >> >> *From:* cisco-voip <[email protected]> on behalf of >> Erick Bergquist <[email protected]> >> *Sent:* Saturday, October 29, 2016 3:31 PM >> *To:* Lelio Fulgenzi >> >> >> *Cc:* cisco voip >> *Subject:* Re: [cisco-voip] Not supported I'm sure..... but what do you >> think? >> >> >> >> Just chiming in on this. >> >> I've done plenty of SU updates using the inactive partition method >> without any issues for most part. I've also done RU updates which are >> fine because updates are planned and done during mtce windows. Most of >> the work I've done is inplace. >> >> Sometimes the mtce window has to be extended due to longer then >> expected time to install the update. This is what is nice about the SU >> update, you can install it ahead of time. If I have a short mtce >> window, I push these a day ahead sometimes just to make sure the SU is >> done installing on all the servers before the reboot / mtce window. >> However, a RU update that needs reboots during the upgrade is >> sometimes harder to get especially if it is a 24x7 shop with minimum >> downtime. >> >> I really haven't had any real issues with any method (SU/RU) except >> one time during switching the servers on different versions where the >> servers were on mismatched versions one subscriber call processing got >> hung up and calls to phones registered on that node were busy. My fix >> was to stop the call manager server and cti manager service >> immediately which solved the problem until that node was switched to >> new version. >> >> The other time I've had issues was with the 10.5.2 SU3 flat version >> and the switch version bug on Unity, but due to way unity works the >> other server was up and running so no real impact to calls. >> >> However, clients are wanting these patches done more and more with no >> impact to calls or very little downtime for 24x7 organizations with >> call centers that operate 24x7. In those upgrade scenarios you need >> this SU/RU update method and patch process to work flawlessly with >> less interruption as possible and hopefully no glitches. >> >> >> On Thu, Oct 27, 2016 at 3:16 PM, Lelio Fulgenzi <[email protected]> >> wrote: >> > >> > This is exactly the reason I did my upgrades off line and swapped out >> the >> > hardware during the maintenance window. >> > >> > >> > That being said, it still took some time to do all the swapping. Just >> > looking at my notes from the last upgrade and it was about 2-3 hours. >> Much >> > of that was due to the amount of time the servers take to shutdown and >> > restart. >> > >> > >> > --- >> > Lelio Fulgenzi, B.A. >> > Senior Analyst, Network Infrastructure >> > Computing and Communications Services (CCS) >> > University of Guelph >> > >> > 519-824-4120 Ext 56354 >> > [email protected] >> > www.uoguelph.ca/ccs >> > Room 037, Animal Science and Nutrition Building >> > Guelph, Ontario, N1G 2W1 >> > >> > >> > >> > ________________________________ >> > From: cisco-voip <[email protected]> on behalf of >> Scott >> > Voll <[email protected]> >> > Sent: Thursday, October 27, 2016 4:50 PM >> > To: Stephen Welsh; Ryan Ratliff >> > Cc: cisco voip >> > >> > Subject: Re: [cisco-voip] Not supported I'm sure..... but what do you >> think? >> > >> > I'm going to start with, we don't have a complex deployment. >> > >> > 2 CM >> > 1 UC >> > 1 UCCX >> > 1 CER >> > 1 call recording server >> > ~2000 phones over ~8 sites >> > >> > our last upgrade we tried PCD (joke) spent 4 hours on it before just >> doing >> > it manually. Will be very hard pressed to every use PCD again. >> > >> > Then it was an additional 12-16 hours to upgrade. This was just a 8 to >> 10 >> > upgrade. >> > >> > We don't have that kind of time. and personally, I like my personal >> time a >> > lot. so the more I can do during the week leading up to the switch and >> as >> > small as I can make the switch, is what I'm looking for. >> > >> > Scott >> > >> > >> > On Thu, Oct 27, 2016 at 1:35 PM, Stephen Welsh < >> [email protected]> >> > wrote: >> >> >> >> I’ve not done CUCM project work in quite a while, so may be completely >> >> off, but what about making this scenario supportable: >> >> >> >> Complex cluster say, 1 Pub, 6 Sub, 2 TFTP >> >> >> >> Install new software to inactive partition on all nodes, once complete >> >> reboot part of the cluster: >> >> >> >> 1 Pub - new version >> >> 3 Sub - new version (primary subs) >> >> 1 TFTP - new version (primary TFTP) >> >> 3 Sub - old version (secondary subs) >> >> 1 TFTP - old version (secondary TFTP) >> >> >> >> Phone registers to upgraded primary subs, once everything >> >> working/stable/tested, flip remaining (secondary nodes) >> >> >> >> Maybe too complex for this split version to be workable, or not really >> >> much different than flipping all nodes, but may allow the phones to >> stay >> >> online with minimal disruption as long as all external elements >> strictly >> >> follow the primary/secondary node configuration. >> >> >> >> Thanks >> >> >> >> Stephen Welsh >> >> CTO >> >> UnifiedFX >> >> >> >> >> >> On 27 Oct 2016, at 21:23, Ryan Huff <[email protected]> wrote: >> >> >> >> >> >> You are right Anthony, this is a complex solution to avoid the reboot >> (and >> >> rolling the dice that nothing breaks in the first boot of the new >> version) >> >> in a switch-version however; if that is your goal .... as you state. >> >> >> >> -R >> >> >> >> ________________________________ >> >> From: [email protected] <[email protected]> on behalf of Anthony >> >> Holloway <[email protected]> >> >> Sent: Thursday, October 27, 2016 12:02 PM >> >> To: Ryan Huff >> >> Cc: Matthew Loraditch; Tommy Schlotterer; Scott Voll; >> >> [email protected] >> >> Subject: Re: [cisco-voip] Not supported I'm sure..... but what do you >> >> think? >> >> >> >> If only there was an upgrade process wherein you install the new >> version >> >> to an inactive partition, and then could switch to the new version when >> >> you're ready. /sarcasm >> >> >> >> But seriously though, everyone in this thread is essentially coming up >> >> with their own clever way of replicating the promise Cisco failed to >> deliver >> >> on, which is performing your upgrades during production on the inactive >> >> partition and then switching versions in a maintenance window. If they >> >> would have only held themselves to a higher standard, we wouldn't need >> this >> >> complex of an alternate solution. >> >> >> >> On Tue, Oct 25, 2016 at 2:45 PM, Ryan Huff <[email protected]> >> wrote: >> >>> >> >>> Matthew is correct, copying is listed as "Supported with Caveats" at: >> >>> http://docwiki.cisco.com/wiki/Unified_Communications_VMware_ >> Requirements; >> >>> The caveat being found at >> >>> http://docwiki.cisco.com/wiki/Unified_Communications_VMware_ >> Requirements#Copy_Virtual_Machine >> >>> >> >>> The VM needs to be powered down first and the resulting VM will have a >> >>> different MAC address (unless it was originally manually specified); >> so >> >>> you'll need to rehost the PLM if it is co-res to any VM that you copy. >> >>> >> >>> Where I have seen folks get into trouble with this is where a >> subscriber >> >>> is copied, and the user mistakenly thinks that by changing the IP and >> >>> hostname it becomes unique and can be added to the cluster as a new >> >>> subscriber. I have also seen users make a copy of a publisher and >> change the >> >>> network details of the copy, thinking it makes a unique cluster and >> then >> >>> wonders why things like ILS wont work between the two clusters (and >> it isn't >> >>> just because the cluster IDs are the same). >> >>> >> >>> Having said all of that, I would NEVER do this in production ... maybe >> >>> that is just me being cautious or old school, but that is just me. >> Even >> >>> without changing network details on the copy, I have seen this cause >> issues >> >>> with Affinity. At the very least, if you travel this path I would >> make sure >> >>> that the copy runs on the same host and even in the same datastore. >> >>> >> >>> === An alternative path === >> >>> >> >>> Admittedly, this path is longer and there is a little more work >> involve >> >>> but is the safer path, IMO and is what I would trust for a production >> >>> scenario. >> >>> >> >>> 1.) Create a private port group on the host. If the cluster is on >> >>> multiple hosts, span the port group through a connecting network to >> the >> >>> other hosts but DO NOT create an SVI anywhere in the the topology for >> that >> >>> DOT1Q tag (remembering to add a DOT1Q tag on any networking devices >> between >> >>> the two hosts and allowing on any trunks between the two hosts). >> >>> >> >>> 2.) Upload Cisco's CSR1000V to the host. If you're not familiar with >> the >> >>> product it is at the core and unlicensed, a virtual router with three >> >>> interfaces by default. Out of the box, it is more than enough to >> replicate >> >>> DNS/NTP on your private network which is all you'll need. Assign the >> private >> >>> port group to the network adapters and configure DNS and NTP (master >> 2) on >> >>> this virtual router. >> >>> >> >>> 3.) Build out a replica of your production UC cluster on the private >> >>> network. >> >>> >> >>> 4.) Take a DRS of the production UC apps and then put your SFTP >> server on >> >>> the private network and do a DRS restore to the private UC apps. >> >>> >> >>> 5.) Upgrade the private UC apps and switch your port group labels on >> the >> >>> production/private UC apps during a maintenance window. >> >>> >> >>> Thanks, >> >>> >> >>> Ryan >> >>> >> >>> >> >>> >> >>> ________________________________ >> >>> From: cisco-voip <[email protected]> on behalf of >> >>> Matthew Loraditch <[email protected]> >> >>> Sent: Tuesday, October 25, 2016 3:01 PM >> >>> To: Tommy Schlotterer; Scott Voll; [email protected] >> >>> >> >>> Subject: Re: [cisco-voip] Not supported I'm sure..... but what do you >> >>> think? >> >>> >> >>> I can’t see any reason it wouldn’t be supported honestly. Offline >> Cloning >> >>> is allowed for migration/backup purposes. I actually did the NAT >> thing to do >> >>> my BE5k to 6K conversions. Kept both systems online. >> >>> >> >>> >> >>> >> >>> The only thing I can think to be thought of is ITLs, does an upgrade >> do >> >>> anything that you’d have to reset phones to go back to the old >> servers if >> >>> there are issues? I don’t think so, but not certain. >> >>> >> >>> >> >>> >> >>> Matthew G. Loraditch – CCNP-Voice, CCNA-R&S, CCDA >> >>> Network Engineer >> >>> Direct Voice: 443.541.1518 >> >>> >> >>> Facebook | Twitter | LinkedIn | G+ >> >>> >> >>> >> >>> >> >>> From: cisco-voip [mailto:[email protected] >> <[email protected]>] On Behalf Of >> >>> Tommy Schlotterer >> >>> Sent: Tuesday, October 25, 2016 2:49 PM >> >>> To: Scott Voll <[email protected]>; [email protected] >> >>> Subject: Re: [cisco-voip] Not supported I'm sure..... but what do you >> >>> think? >> >>> >> >>> >> >>> >> >>> I do a similar, but supported process. I take DRS backups and then >> >>> restore on servers in a sandbox VLAN. Works well. Make sure you check >> your >> >>> phone firmware and upgrade to the current version before the cutover >> or all >> >>> your phones will have to upgrade on cutover. >> >>> >> >>> >> >>> >> >>> Also make sure you don’t change Hostname/Ip addresses in the sandbox >> as >> >>> that will cause your ITL to regenerate and cause issues with phone >> >>> configuration changes after cutover. >> >>> >> >>> >> >>> >> >>> Thanks >> >>> >> >>> Tommy >> >>> >> >>> >> >>> >> >>> Tommy Schlotterer | Systems Engineer >> >>> Presidio | www.presidio.com >> >>> 20 N. Saint Clair, 3rd Floor, Toledo, OH 43604 >> >>> D: 419.214.1415 | C: 419.706.0259 | [email protected] >> >>> >> >>> >> >>> >> >>> From: cisco-voip [mailto:[email protected] >> <[email protected]>] On Behalf Of >> >>> Scott Voll >> >>> Sent: Tuesday, October 25, 2016 2:43 PM >> >>> To: [email protected] >> >>> Subject: [cisco-voip] Not supported I'm sure..... but what do you >> think? >> >>> >> >>> >> >>> >> >>> So my co-worker and I are thinking about upgrades. we are currently >> on >> >>> 10.5 train and thinking about the 11.5 train. >> >>> >> >>> >> >>> >> >>> What would be your thoughts about taking a clone of every VM. CM, UC, >> >>> UCCx, CER, PLM, >> >>> >> >>> >> >>> >> >>> placing it on another vlan with the same IP's. NAT it as it goes onto >> >>> your network so it has access to NTP, DNS, AD, etc. >> >>> >> >>> >> >>> >> >>> do your upgrade on the clones. >> >>> >> >>> >> >>> >> >>> Then in VM ware shut down the originals,and change the Vlan (on the >> >>> clones) back to the production vlan for your voice cluster. >> >>> >> >>> >> >>> >> >>> it would be like a telco slash cut. 10 minute outage as you move from >> >>> one version to the other. >> >>> >> >>> >> >>> >> >>> Thoughts? >> >>> >> >>> >> >>> >> >>> Scott >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> This message w/attachments (message) is intended solely for the use of >> >>> the intended recipient(s) and may contain information that is >> privileged, >> >>> confidential or proprietary. If you are not an intended recipient, >> please >> >>> notify the sender, and then please delete and destroy all copies and >> >>> attachments. Please be advised that any review or dissemination of, >> or the >> >>> taking of any action in reliance on, the information contained in or >> >>> attached to this message is prohibited. >> >>> >> >>> _______________________________________________ >> >>> 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 >> >> >> > >> > >> > _______________________________________________ >> > 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 >> >> >> >> >> _______________________________________________ >> 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 > > _______________________________________________ > 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
