<p dir="ltr"><a href="http://ciscounitytools.com/Applications/CxN/MessageShuttle/MessageShuttle.html">http://ciscounitytools.com/Applications/CxN/MessageShuttle/MessageShuttle.html</a></p>
<p dir="ltr">TAC supported even.</p>
<div class="gmail_extra"><br><div class="gmail_quote">On Oct 31, 2016 9:12 PM, "Lelio Fulgenzi" <<a href="mailto:lelio@uoguelph.ca">lelio@uoguelph.ca</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="auto">
<div>What is this message shuttle magic you soak of?<br>
<br>
Sent from my iPhone</div>
<div><br>
On Oct 31, 2016, at 5:37 PM, Ryan Huff <<a href="mailto:ryanhuff@outlook.com" target="_blank">ryanhuff@outlook.com</a>> wrote:<br>
<br>
</div>
<blockquote type="cite">
<div>
<div>Plus +1 to Anthony</div>
<div id="m_-5238289692611337983AppleMailSignature"><br>
</div>
<div id="m_-5238289692611337983AppleMailSignature">Message shuttle is silly fast too as it is just doing file copies and not going through the COBRAS overhead.</div>
<div id="m_-5238289692611337983AppleMailSignature"><br>
</div>
<div id="m_-5238289692611337983AppleMailSignature">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)</div>
<div id="m_-5238289692611337983AppleMailSignature"><br>
</div>
<div id="m_-5238289692611337983AppleMailSignature">2.) Message shuttle right before the switch to move content.</div>
<div id="m_-5238289692611337983AppleMailSignature"><br>
</div>
<div id="m_-5238289692611337983AppleMailSignature">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.</div>
<div id="m_-5238289692611337983AppleMailSignature"><br>
-Ryan</div>
<div><br>
On Oct 31, 2016, at 5:28 PM, Anthony Holloway <<a href="mailto:avholloway+cisco-voip@gmail.com" target="_blank">avholloway+cisco-voip@gmail.<wbr>com</a>> wrote:<br>
<br>
</div>
<blockquote type="cite">
<div>
<div dir="ltr">Or Message Shuttle?</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Mon, Oct 31, 2016 at 11:10 AM, Matthew Loraditch <span dir="ltr">
<<a href="mailto:MLoraditch@heliontechnologies.com" target="_blank">MLoraditch@<wbr>heliontechnologies.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="EN-US" link="blue" vlink="purple">
<div class="m_-5238289692611337983m_3925718856393468279WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">COBRAS would work for that.<u></u><u></u></span></p>
<span>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Matthew G. Loraditch – CCNP-Voice, CCNA-R&S, CCDA<br>
Network Engineer<br>
Direct Voice: <a href="tel:443.541.1518" value="+14435411518" target="_blank">443.541.1518</a></span><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><br>
<br>
<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><a href="https://www.facebook.com/heliontech?ref=hl" target="_blank"><span style="font-size:8.0pt">Facebook</span></a></span><span style="font-size:8.0pt;font-family:"Calibri",sans-serif;color:#1f497d">
| </span><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><a href="https://twitter.com/HelionTech" target="_blank"><span style="font-size:8.0pt">Twitter</span></a></span><span style="font-size:8.0pt;font-family:"Calibri",sans-serif;color:#1f497d">
| </span><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><a href="https://www.linkedin.com/company/helion-technologies?trk=top_nav_home" target="_blank"><span style="font-size:8.0pt">LinkedIn</span></a></span><span style="font-size:8.0pt;font-family:"Calibri",sans-serif;color:#1f497d">
| </span><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><a href="https://plus.google.com/+Heliontechnologies/posts" target="_blank"><span style="font-size:8.0pt">G+</span></a><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
</span>
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> cisco-voip [mailto:<a href="mailto:cisco-voip-bounces@puck.nether.net" target="_blank">cisco-voip-bounces@puc<wbr>k.nether.net</a>]
<b>On Behalf Of </b>Scott Voll<br>
<b>Sent:</b> Monday, October 31, 2016 12:08 PM<br>
<b>To:</b> Peter Slow <<a href="mailto:peter.slow@gmail.com" target="_blank">peter.slow@gmail.com</a>><br>
<b>Cc:</b> cisco voip <<a href="mailto:cisco-voip@puck.nether.net" target="_blank">cisco-voip@puck.nether.net</a>></span></p>
<div>
<div class="m_-5238289692611337983h5"><br>
<b>Subject:</b> Re: [cisco-voip] Not supported I'm sure..... but what do you think?<u></u><u></u></div>
</div>
<p></p>
<div>
<div class="m_-5238289692611337983h5">
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">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?<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Scott<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">On Sat, Oct 29, 2016 at 2:03 PM, Peter Slow <<a href="mailto:peter.slow@gmail.com" target="_blank">peter.slow@gmail.com</a>> wrote:<u></u><u></u></p>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<p class="MsoNormal">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. <u></u><u></u></p>
<div>
<p class="MsoNormal">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.<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">BE CAREFUL IF YOU DO THIS <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">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.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">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.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">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.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">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)<u></u><u></u></p>
</div>
<div>
<div>
<p class="MsoNormal"><span style="color:#888888"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#888888">-Peter<u></u><u></u></span></p>
</div>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">On Sat, Oct 29, 2016 at 1:28 PM, Ryan Huff <<a href="mailto:ryanhuff@outlook.com" target="_blank">ryanhuff@outlook.com</a>> wrote:<u></u><u></u></p>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div id="m_-5238289692611337983m_3925718856393468279m_1269514956285409227m_1540560206496211586divtagdefaultwrapper">
<p><span style="font-family:"Calibri",sans-serif;color:black">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.<u></u><u></u></span></p>
<p><span style="font-family:"Calibri",sans-serif;color:black"><u></u> <u></u></span></p>
<p><span style="font-family:"Calibri",sans-serif;color:black">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:<u></u><u></u></span></p>
<p><span style="font-family:"Calibri",sans-serif;color:black"><u></u> <u></u></span></p>
<p><span style="font-family:"Calibri",sans-serif;color:black">"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.<u></u><u></u></span></p>
<p><span style="font-family:"Calibri",sans-serif;color:black"><u></u> <u></u></span></p>
<p><span style="font-family:"Calibri",sans-serif;color:black">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.<u></u><u></u></span></p>
<p><span style="font-family:"Calibri",sans-serif;color:black"><u></u> <u></u></span></p>
<p><span style="font-family:"Calibri",sans-serif;color:black">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.
<u></u><u></u></span></p>
<p><span style="font-family:"Calibri",sans-serif;color:black"><u></u> <u></u></span></p>
<p><span style="font-family:"Calibri",sans-serif;color:black">All of that is possible, but would require a serious re-tool at the RedHat level.<u></u><u></u></span></p>
<p><span style="font-family:"Calibri",sans-serif;color:black"><u></u> <u></u></span></p>
<p><span style="font-family:"Calibri",sans-serif;color:black"><u></u> <u></u></span></p>
<div id="m_-5238289692611337983m_3925718856393468279m_1269514956285409227m_1540560206496211586Signature">
<div id="m_-5238289692611337983m_3925718856393468279m_1269514956285409227m_1540560206496211586divtagdefaultwrapper">
<p class="MsoNormal" style="background:white"><span style="font-family:"Calibri",sans-serif;color:black">= Ryan =
<u></u><u></u></span></p>
<p style="background:white"><span style="font-family:"Calibri",sans-serif;color:black"><u></u> <u></u></span></p>
</div>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-family:"Calibri",sans-serif;color:black"><u></u> <u></u></span></p>
<div>
<div>
<div class="MsoNormal" align="center" style="text-align:center"><span style="font-family:"Calibri",sans-serif;color:black">
<hr size="2" width="98%" align="center">
</span></div>
<div id="m_-5238289692611337983m_3925718856393468279m_1269514956285409227m_1540560206496211586x_divRplyFwdMsg">
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:black">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:black"> cisco-voip <<a href="mailto:cisco-voip-bounces@puck.nether.net" target="_blank">cisco-voip-bounces@puck.nethe<wbr>r.net</a>>
on behalf of Erick Bergquist <<a href="mailto:erickbee@gmail.com" target="_blank">erickbee@gmail.com</a>><br>
<b>Sent:</b> Saturday, October 29, 2016 3:31 PM<br>
<b>To:</b> Lelio Fulgenzi<u></u><u></u></span></p>
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:black"><br>
<b>Cc:</b> cisco voip<br>
<b>Subject:</b> Re: [cisco-voip] Not supported I'm sure..... but what do you think?<u></u><u></u></span></p>
</div>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif;color:black"> <u></u><u></u></span></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Calibri",sans-serif;color:black">Just chiming in on this.<br>
<br>
I've done plenty of SU updates using the inactive partition method<br>
without any issues for most part. I've also done RU updates which are<br>
fine because updates are planned and done during mtce windows. Most of<br>
the work I've done is inplace.<br>
<br>
Sometimes the mtce window has to be extended due to longer then<br>
expected time to install the update. This is what is nice about the SU<br>
update, you can install it ahead of time. If I have a short mtce<br>
window, I push these a day ahead sometimes just to make sure the SU is<br>
done installing on all the servers before the reboot / mtce window.<br>
However, a RU update that needs reboots during the upgrade is<br>
sometimes harder to get especially if it is a 24x7 shop with minimum<br>
downtime.<br>
<br>
I really haven't had any real issues with any method (SU/RU) except<br>
one time during switching the servers on different versions where the<br>
servers were on mismatched versions one subscriber call processing got<br>
hung up and calls to phones registered on that node were busy. My fix<br>
was to stop the call manager server and cti manager service<br>
immediately which solved the problem until that node was switched to<br>
new version.<br>
<br>
The other time I've had issues was with the 10.5.2 SU3 flat version<br>
and the switch version bug on Unity, but due to way unity works the<br>
other server was up and running so no real impact to calls.<br>
<br>
However, clients are wanting these patches done more and more with no<br>
impact to calls or very little downtime for 24x7 organizations with<br>
call centers that operate 24x7. In those upgrade scenarios you need<br>
this SU/RU update method and patch process to work flawlessly with<br>
less interruption as possible and hopefully no glitches.<br>
<br>
<br>
On Thu, Oct 27, 2016 at 3:16 PM, Lelio Fulgenzi <<a href="mailto:lelio@uoguelph.ca" target="_blank">lelio@uoguelph.ca</a>> wrote:<br>
><br>
> This is exactly the reason I did my upgrades off line and swapped out the<br>
> hardware during the maintenance window.<br>
><br>
><br>
> That being said, it still took some time to do all the swapping. Just<br>
> looking at my notes from the last upgrade and it was about 2-3 hours. Much<br>
> of that was due to the amount of time the servers take to shutdown and<br>
> restart.<br>
><br>
><br>
> ---<br>
> Lelio Fulgenzi, B.A.<br>
> Senior Analyst, Network Infrastructure<br>
> Computing and Communications Services (CCS)<br>
> University of Guelph<br>
><br>
> <a href="tel:519-824-4120%20Ext%2056354" target="_blank">519-824-4120 Ext 56354</a><br>
> <a href="mailto:lelio@uoguelph.ca" target="_blank">lelio@uoguelph.ca</a><br>
> <a href="http://www.uoguelph.ca/ccs" target="_blank">www.uoguelph.ca/ccs</a><br>
> Room 037, Animal Science and Nutrition Building<br>
> Guelph, Ontario, N1G 2W1<br>
><br>
><br>
><br>
> ______________________________<wbr>__<br>
> From: cisco-voip <<a href="mailto:cisco-voip-bounces@puck.nether.net" target="_blank">cisco-voip-bounces@puck.nethe<wbr>r.net</a>> on behalf of Scott<br>
> Voll <<a href="mailto:svoll.voip@gmail.com" target="_blank">svoll.voip@gmail.com</a>><br>
> Sent: Thursday, October 27, 2016 4:50 PM<br>
> To: Stephen Welsh; Ryan Ratliff<br>
> Cc: cisco voip<br>
><br>
> Subject: Re: [cisco-voip] Not supported I'm sure..... but what do you think?<br>
><br>
> I'm going to start with, we don't have a complex deployment.<br>
><br>
> 2 CM<br>
> 1 UC<br>
> 1 UCCX<br>
> 1 CER<br>
> 1 call recording server<br>
> ~2000 phones over ~8 sites<br>
><br>
> our last upgrade we tried PCD (joke) spent 4 hours on it before just doing<br>
> it manually. Will be very hard pressed to every use PCD again.<br>
><br>
> Then it was an additional 12-16 hours to upgrade. This was just a 8 to 10<br>
> upgrade.<br>
><br>
> We don't have that kind of time. and personally, I like my personal time a<br>
> lot. so the more I can do during the week leading up to the switch and as<br>
> small as I can make the switch, is what I'm looking for.<br>
><br>
> Scott<br>
><br>
><br>
> On Thu, Oct 27, 2016 at 1:35 PM, Stephen Welsh <<a href="mailto:stephen.welsh@unifiedfx.com" target="_blank">stephen.welsh@unifiedfx.com</a>><br>
> wrote:<br>
>><br>
>> I’ve not done CUCM project work in quite a while, so may be completely<br>
>> off, but what about making this scenario supportable:<br>
>><br>
>> Complex cluster say, 1 Pub, 6 Sub, 2 TFTP<br>
>><br>
>> Install new software to inactive partition on all nodes, once complete<br>
>> reboot part of the cluster:<br>
>><br>
>> 1 Pub - new version<br>
>> 3 Sub - new version (primary subs)<br>
>> 1 TFTP - new version (primary TFTP)<br>
>> 3 Sub - old version (secondary subs)<br>
>> 1 TFTP - old version (secondary TFTP)<br>
>><br>
>> Phone registers to upgraded primary subs, once everything<br>
>> working/stable/tested, flip remaining (secondary nodes)<br>
>><br>
>> Maybe too complex for this split version to be workable, or not really<br>
>> much different than flipping all nodes, but may allow the phones to stay<br>
>> online with minimal disruption as long as all external elements strictly<br>
>> follow the primary/secondary node configuration.<br>
>><br>
>> Thanks<br>
>><br>
>> Stephen Welsh<br>
>> CTO<br>
>> UnifiedFX<br>
>><br>
>><br>
>> On 27 Oct 2016, at 21:23, Ryan Huff <<a href="mailto:ryanhuff@outlook.com" target="_blank">ryanhuff@outlook.com</a>> wrote:<br>
>><br>
>><br>
>> You are right Anthony, this is a complex solution to avoid the reboot (and<br>
>> rolling the dice that nothing breaks in the first boot of the new version)<br>
>> in a switch-version however; if that is your goal .... as you state.<br>
>><br>
>> -R<br>
>><br>
>> ______________________________<wbr>__<br>
>> From: <a href="mailto:avholloway@gmail.com" target="_blank">avholloway@gmail.com</a> <<a href="mailto:avholloway@gmail.com" target="_blank">avholloway@gmail.com</a>> on behalf of Anthony<br>
>> Holloway <<a href="mailto:avholloway%2Bcisco-voip@gmail.com" target="_blank">avholloway+cisco-voip@gmail.c<wbr>om</a>><br>
>> Sent: Thursday, October 27, 2016 12:02 PM<br>
>> To: Ryan Huff<br>
>> Cc: Matthew Loraditch; Tommy Schlotterer; Scott Voll;<br>
>> <a href="mailto:cisco-voip@puck.nether.net" target="_blank">cisco-voip@puck.nether.net</a><br>
>> Subject: Re: [cisco-voip] Not supported I'm sure..... but what do you<br>
>> think?<br>
>><br>
>> If only there was an upgrade process wherein you install the new version<br>
>> to an inactive partition, and then could switch to the new version when<br>
>> you're ready. /sarcasm<br>
>><br>
>> But seriously though, everyone in this thread is essentially coming up<br>
>> with their own clever way of replicating the promise Cisco failed to deliver<br>
>> on, which is performing your upgrades during production on the inactive<br>
>> partition and then switching versions in a maintenance window. If they<br>
>> would have only held themselves to a higher standard, we wouldn't need this<br>
>> complex of an alternate solution.<br>
>><br>
>> On Tue, Oct 25, 2016 at 2:45 PM, Ryan Huff <<a href="mailto:ryanhuff@outlook.com" target="_blank">ryanhuff@outlook.com</a>> wrote:<br>
>>><br>
>>> Matthew is correct, copying is listed as "Supported with Caveats" at:<br>
>>> <a href="http://docwiki.cisco.com/wiki/Unified_Communications_VMware_Requirements" target="_blank">
http://docwiki.cisco.com/wiki/<wbr>Unified_Communications_VMware_<wbr>Requirements</a>;<br>
>>> The caveat being found at<br>
>>> <a href="http://docwiki.cisco.com/wiki/Unified_Communications_VMware_Requirements#Copy_Virtual_Machine" target="_blank">
http://docwiki.cisco.com/wiki/<wbr>Unified_Communications_VMware_<wbr>Requirements#Copy_Virtual_Mach<wbr>ine</a><br>
>>><br>
>>> The VM needs to be powered down first and the resulting VM will have a<br>
>>> different MAC address (unless it was originally manually specified); so<br>
>>> you'll need to rehost the PLM if it is co-res to any VM that you copy.<br>
>>><br>
>>> Where I have seen folks get into trouble with this is where a subscriber<br>
>>> is copied, and the user mistakenly thinks that by changing the IP and<br>
>>> hostname it becomes unique and can be added to the cluster as a new<br>
>>> subscriber. I have also seen users make a copy of a publisher and change the<br>
>>> network details of the copy, thinking it makes a unique cluster and then<br>
>>> wonders why things like ILS wont work between the two clusters (and it isn't<br>
>>> just because the cluster IDs are the same).<br>
>>><br>
>>> Having said all of that, I would NEVER do this in production ... maybe<br>
>>> that is just me being cautious or old school, but that is just me. Even<br>
>>> without changing network details on the copy, I have seen this cause issues<br>
>>> with Affinity. At the very least, if you travel this path I would make sure<br>
>>> that the copy runs on the same host and even in the same datastore.<br>
>>><br>
>>> === An alternative path ===<br>
>>><br>
>>> Admittedly, this path is longer and there is a little more work involve<br>
>>> but is the safer path, IMO and is what I would trust for a production<br>
>>> scenario.<br>
>>><br>
>>> 1.) Create a private port group on the host. If the cluster is on<br>
>>> multiple hosts, span the port group through a connecting network to the<br>
>>> other hosts but DO NOT create an SVI anywhere in the the topology for that<br>
>>> DOT1Q tag (remembering to add a DOT1Q tag on any networking devices between<br>
>>> the two hosts and allowing on any trunks between the two hosts).<br>
>>><br>
>>> 2.) Upload Cisco's CSR1000V to the host. If you're not familiar with the<br>
>>> product it is at the core and unlicensed, a virtual router with three<br>
>>> interfaces by default. Out of the box, it is more than enough to replicate<br>
>>> DNS/NTP on your private network which is all you'll need. Assign the private<br>
>>> port group to the network adapters and configure DNS and NTP (master 2) on<br>
>>> this virtual router.<br>
>>><br>
>>> 3.) Build out a replica of your production UC cluster on the private<br>
>>> network.<br>
>>><br>
>>> 4.) Take a DRS of the production UC apps and then put your SFTP server on<br>
>>> the private network and do a DRS restore to the private UC apps.<br>
>>><br>
>>> 5.) Upgrade the private UC apps and switch your port group labels on the<br>
>>> production/private UC apps during a maintenance window.<br>
>>><br>
>>> Thanks,<br>
>>><br>
>>> Ryan<br>
>>><br>
>>><br>
>>><br>
>>> ______________________________<wbr>__<br>
>>> From: cisco-voip <<a href="mailto:cisco-voip-bounces@puck.nether.net" target="_blank">cisco-voip-bounces@puck.nethe<wbr>r.net</a>> on behalf of<br>
>>> Matthew Loraditch <<a href="mailto:MLoraditch@heliontechnologies.com" target="_blank">MLoraditch@heliontechnologies<wbr>.com</a>><br>
>>> Sent: Tuesday, October 25, 2016 3:01 PM<br>
>>> To: Tommy Schlotterer; Scott Voll; <a href="mailto:cisco-voip@puck.nether.net" target="_blank">
cisco-voip@puck.nether.net</a><br>
>>><br>
>>> Subject: Re: [cisco-voip] Not supported I'm sure..... but what do you<br>
>>> think?<br>
>>><br>
>>> I can’t see any reason it wouldn’t be supported honestly. Offline Cloning<br>
>>> is allowed for migration/backup purposes. I actually did the NAT thing to do<br>
>>> my BE5k to 6K conversions. Kept both systems online.<br>
>>><br>
>>><br>
>>><br>
>>> The only thing I can think to be thought of is ITLs, does an upgrade do<br>
>>> anything that you’d have to reset phones to go back to the old servers if<br>
>>> there are issues? I don’t think so, but not certain.<br>
>>><br>
>>><br>
>>><br>
>>> Matthew G. Loraditch – CCNP-Voice, CCNA-R&S, CCDA<br>
>>> Network Engineer<br>
>>> Direct Voice: <a href="tel:443.541.1518" target="_blank">443.541.1518</a><br>
>>><br>
>>> Facebook | Twitter | LinkedIn | G+<br>
>>><br>
>>><br>
>>><br>
>>> From: cisco-voip [<a href="mailto:cisco-voip-bounces@puck.nether.net" target="_blank">mailto:cisco-voip-bounces@puc<wbr>k.nether.net</a>] On Behalf Of<br>
>>> Tommy Schlotterer<br>
>>> Sent: Tuesday, October 25, 2016 2:49 PM<br>
>>> To: Scott Voll <<a href="mailto:svoll.voip@gmail.com" target="_blank">svoll.voip@gmail.com</a>>;
<a href="mailto:cisco-voip@puck.nether.net" target="_blank">cisco-voip@puck.nether.net</a><br>
>>> Subject: Re: [cisco-voip] Not supported I'm sure..... but what do you<br>
>>> think?<br>
>>><br>
>>><br>
>>><br>
>>> I do a similar, but supported process. I take DRS backups and then<br>
>>> restore on servers in a sandbox VLAN. Works well. Make sure you check your<br>
>>> phone firmware and upgrade to the current version before the cutover or all<br>
>>> your phones will have to upgrade on cutover.<br>
>>><br>
>>><br>
>>><br>
>>> Also make sure you don’t change Hostname/Ip addresses in the sandbox as<br>
>>> that will cause your ITL to regenerate and cause issues with phone<br>
>>> configuration changes after cutover.<br>
>>><br>
>>><br>
>>><br>
>>> Thanks<br>
>>><br>
>>> Tommy<br>
>>><br>
>>><br>
>>><br>
>>> Tommy Schlotterer | Systems Engineer<br>
>>> Presidio | <a href="http://www.presidio.com" target="_blank">www.presidio.com</a><br>
>>> 20 N. Saint Clair, 3rd Floor, Toledo, OH 43604<br>
>>> D: <a href="tel:419.214.1415" target="_blank">419.214.1415</a> | C: <a href="tel:419.706.0259" target="_blank">
419.706.0259</a> | <a href="mailto:tschlotterer@presidio.com" target="_blank">tschlotterer@presidio.com</a><br>
>>><br>
>>><br>
>>><br>
>>> From: cisco-voip [<a href="mailto:cisco-voip-bounces@puck.nether.net" target="_blank">mailto:cisco-voip-bounces@puc<wbr>k.nether.net</a>] On Behalf Of<br>
>>> Scott Voll<br>
>>> Sent: Tuesday, October 25, 2016 2:43 PM<br>
>>> To: <a href="mailto:cisco-voip@puck.nether.net" target="_blank">cisco-voip@puck.nether.net</a><br>
>>> Subject: [cisco-voip] Not supported I'm sure..... but what do you think?<br>
>>><br>
>>><br>
>>><br>
>>> So my co-worker and I are thinking about upgrades. we are currently on<br>
>>> 10.5 train and thinking about the 11.5 train.<br>
>>><br>
>>><br>
>>><br>
>>> What would be your thoughts about taking a clone of every VM. CM, UC,<br>
>>> UCCx, CER, PLM,<br>
>>><br>
>>><br>
>>><br>
>>> placing it on another vlan with the same IP's. NAT it as it goes onto<br>
>>> your network so it has access to NTP, DNS, AD, etc.<br>
>>><br>
>>><br>
>>><br>
>>> do your upgrade on the clones.<br>
>>><br>
>>><br>
>>><br>
>>> Then in VM ware shut down the originals,and change the Vlan (on the<br>
>>> clones) back to the production vlan for your voice cluster.<br>
>>><br>
>>><br>
>>><br>
>>> it would be like a telco slash cut. 10 minute outage as you move from<br>
>>> one version to the other.<br>
>>><br>
>>><br>
>>><br>
>>> Thoughts?<br>
>>><br>
>>><br>
>>><br>
>>> Scott<br>
>>><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>> This message w/attachments (message) is intended solely for the use of<br>
>>> the intended recipient(s) and may contain information that is privileged,<br>
>>> confidential or proprietary. If you are not an intended recipient, please<br>
>>> notify the sender, and then please delete and destroy all copies and<br>
>>> attachments. Please be advised that any review or dissemination of, or the<br>
>>> taking of any action in reliance on, the information contained in or<br>
>>> attached to this message is prohibited.<br>
>>><br>
>>> ______________________________<wbr>_________________<br>
>>> cisco-voip mailing list<br>
>>> <a href="mailto:cisco-voip@puck.nether.net" target="_blank">cisco-voip@puck.nether.net</a><br>
>>> <a href="https://puck.nether.net/mailman/listinfo/cisco-voip" target="_blank">
https://puck.nether.net/mailma<wbr>n/listinfo/cisco-voip</a><br>
>>><br>
>><br>
>> ______________________________<wbr>_________________<br>
>> cisco-voip mailing list<br>
>> <a href="mailto:cisco-voip@puck.nether.net" target="_blank">cisco-voip@puck.nether.net</a><br>
>> <a href="https://puck.nether.net/mailman/listinfo/cisco-voip" target="_blank">
https://puck.nether.net/mailma<wbr>n/listinfo/cisco-voip</a><br>
>><br>
>><br>
>><br>
>> ______________________________<wbr>_________________<br>
>> cisco-voip mailing list<br>
>> <a href="mailto:cisco-voip@puck.nether.net" target="_blank">cisco-voip@puck.nether.net</a><br>
>> <a href="https://puck.nether.net/mailman/listinfo/cisco-voip" target="_blank">
https://puck.nether.net/mailma<wbr>n/listinfo/cisco-voip</a><br>
>><br>
><br>
><br>
> ______________________________<wbr>_________________<br>
> cisco-voip mailing list<br>
> <a href="mailto:cisco-voip@puck.nether.net" target="_blank">cisco-voip@puck.nether.net</a><br>
> <a href="https://puck.nether.net/mailman/listinfo/cisco-voip" target="_blank">https://puck.nether.net/mailma<wbr>n/listinfo/cisco-voip</a><br>
><br>
______________________________<wbr>_________________<br>
cisco-voip mailing list<br>
<a href="mailto:cisco-voip@puck.nether.net" target="_blank">cisco-voip@puck.nether.net</a><br>
<a href="https://puck.nether.net/mailman/listinfo/cisco-voip" target="_blank">https://puck.nether.net/mailma<wbr>n/listinfo/cisco-voip</a><u></u><u></u></span></p>
</div>
</div>
</div>
</div>
</div>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
______________________________<wbr>_________________<br>
cisco-voip mailing list<br>
<a href="mailto:cisco-voip@puck.nether.net" target="_blank">cisco-voip@puck.nether.net</a><br>
<a href="https://puck.nether.net/mailman/listinfo/cisco-voip" target="_blank">https://puck.nether.net/mailma<wbr>n/listinfo/cisco-voip</a><u></u><u></u></p>
</blockquote>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
______________________________<wbr>_________________<br>
cisco-voip mailing list<br>
<a href="mailto:cisco-voip@puck.nether.net" target="_blank">cisco-voip@puck.nether.net</a><br>
<a href="https://puck.nether.net/mailman/listinfo/cisco-voip" target="_blank">https://puck.nether.net/mailma<wbr>n/listinfo/cisco-voip</a><u></u><u></u></p>
</blockquote>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
</div>
</div>
</div>
<br>
______________________________<wbr>_________________<br>
cisco-voip mailing list<br>
<a href="mailto:cisco-voip@puck.nether.net" target="_blank">cisco-voip@puck.nether.net</a><br>
<a href="https://puck.nether.net/mailman/listinfo/cisco-voip" rel="noreferrer" target="_blank">https://puck.nether.net/mailma<wbr>n/listinfo/cisco-voip</a><br>
<br>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
<blockquote type="cite">
<div><span>______________________________<wbr>_________________</span><br>
<span>cisco-voip mailing list</span><br>
<span><a href="mailto:cisco-voip@puck.nether.net" target="_blank">cisco-voip@puck.nether.net</a></span><br>
<span><a href="https://puck.nether.net/mailman/listinfo/cisco-voip" target="_blank">https://puck.nether.net/<wbr>mailman/listinfo/cisco-voip</a></span><br>
</div>
</blockquote>
</div>
</blockquote>
<blockquote type="cite">
<div><span>______________________________<wbr>_________________</span><br>
<span>cisco-voip mailing list</span><br>
<span><a href="mailto:cisco-voip@puck.nether.net" target="_blank">cisco-voip@puck.nether.net</a></span><br>
<span><a href="https://puck.nether.net/mailman/listinfo/cisco-voip" target="_blank">https://puck.nether.net/<wbr>mailman/listinfo/cisco-voip</a></span><br>
</div>
</blockquote>
</div>
<br>______________________________<wbr>_________________<br>
cisco-voip mailing list<br>
<a href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a><br>
<a href="https://puck.nether.net/mailman/listinfo/cisco-voip" rel="noreferrer" target="_blank">https://puck.nether.net/<wbr>mailman/listinfo/cisco-voip</a><br>
<br></blockquote></div></div>